Fix for BUG#16559 "Replication Problems with Non transactional tables inside an interrupted trans.":

problem was: when a connection disconnects having an open transaction affecting MyISAM and InnoDB, the ROLLBACK event stored in the binary log
contained a non-zero error code (1053 because of the disconnection), so when slave applied the transaction, slave complained that its ROLLBACK succeeded
(error_code=0) while master's had 1053, so slave stopped. But internally generated binlog events such as this ROLLBACK
should always have 0 as error code, as is true in 4.1 and was accidentally broken in 5.0,
so that there is no false alarm.


mysql-test/r/mix_innodb_myisam_binlog.result:
  result update
mysql-test/t/mix_innodb_myisam_binlog.test:
  test for BUG#16559
sql/log.cc:
  Internally generated binlog events should always have an error code of zero (like in 4.1; in 5.0 this was accidentally broken).

1 files changed, 5 insertions, 1 deletions

diff --git a/sql/log.cc b/sql/log.cc
index 6c37cb04c61..85e8c4dae2f 100644
--- a/sql/log.cc
+++ b/sql/log.cc
@@ -132,6 +132,7 @@ static int binlog_commit(THD *thd, bool all)
     DBUG_RETURN(0);
   }
   Query_log_event qev(thd, STRING_WITH_LEN("COMMIT"), TRUE, FALSE);
+  qev.error_code= 0; // see comment in MYSQL_LOG::write(THD, IO_CACHE)
   DBUG_RETURN(binlog_end_trans(thd, trans_log, &qev));
 }
 
@@ -156,6 +157,7 @@ static int binlog_rollback(THD *thd, bool all)
   if (unlikely(thd->options & OPTION_STATUS_NO_TRANS_UPDATE))
   {
     Query_log_event qev(thd, STRING_WITH_LEN("ROLLBACK"), TRUE, FALSE);
+    qev.error_code= 0; // see comment in MYSQL_LOG::write(THD, IO_CACHE)
     error= binlog_end_trans(thd, trans_log, &qev);
   }
   else
@@ -1826,7 +1828,9 @@ bool MYSQL_LOG::write(THD *thd, IO_CACHE *cache, Log_event *commit_event)
         Imagine this is rollback due to net timeout, after all statements of
         the transaction succeeded. Then we want a zero-error code in BEGIN.
         In other words, if there was a really serious error code it's already
-        in the statement's events.
+        in the statement's events, there is no need to put it also in this
+        internally generated event, and as this event is generated late it
+        would lead to false alarms.
         This is safer than thd->clear_error() against kills at shutdown.
       */
       qinfo.error_code= 0;