diff options
author | guilhem@mysql.com <> | 2006-02-18 17:19:16 +0100 |
---|---|---|
committer | guilhem@mysql.com <> | 2006-02-18 17:19:16 +0100 |
commit | 4c5d18b1505fe4fbbfd51268df0784d9c3faf983 (patch) | |
tree | 6c8e6c047b411b83d6898b8886439ae27bac640c /sql/log.cc | |
parent | cb74e09f46fa214cae0523dbe1e15b69218c4fdf (diff) | |
download | mariadb-git-4c5d18b1505fe4fbbfd51268df0784d9c3faf983.tar.gz |
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.
Diffstat (limited to 'sql/log.cc')
-rw-r--r-- | sql/log.cc | 6 |
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; |