summaryrefslogtreecommitdiff
path: root/sql/log.cc
diff options
context:
space:
mode:
authorguilhem@mysql.com <>2006-02-18 17:19:16 +0100
committerguilhem@mysql.com <>2006-02-18 17:19:16 +0100
commit4c5d18b1505fe4fbbfd51268df0784d9c3faf983 (patch)
tree6c8e6c047b411b83d6898b8886439ae27bac640c /sql/log.cc
parentcb74e09f46fa214cae0523dbe1e15b69218c4fdf (diff)
downloadmariadb-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.cc6
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;