mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2026-04-30 04:05:32 +02:00
Code Issues Projects Releases Packages Wiki Activity

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

Browse source 
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).
This commit is contained in:
unknown 2006-02-18 17:19:16 +01:00
commit cefc0b6dff
3 changed files with 60 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

6
sql/log.cc
View file

@ -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;