summaryrefslogtreecommitdiff
path: root/sql/log_event.cc
diff options
context:
space:
mode:
authorunknown <knielsen@knielsen-hq.org>2010-11-30 10:47:08 +0100
committerunknown <knielsen@knielsen-hq.org>2010-11-30 10:47:08 +0100
commite46d0aead03c2c719a05c97d2ce7f94eee51a9f6 (patch)
treef4727b4ae88c68b797a3517120daf0df5aa1c59f /sql/log_event.cc
parentd54f869f8c34e5bb93ab187cfc6495f9e192c259 (diff)
downloadmariadb-git-e46d0aead03c2c719a05c97d2ce7f94eee51a9f6.tar.gz
Bug#54201: "SET INSERT_ID" event must be ignored if corresponding event is ignored
An INSERT query log event is preceeded by an INSERT_ID intvar event if the INSERT allocates a new auto_increment value. But if we ignore the INSERT due to --replicate-ignore-table or similar, then the INSERT_ID event is still executed, and the set value of INSERT_ID lingers around in the slave sql thread THD object indefinitely until the next INSERT that happens to need allocation of a new auto_increment value. Normally this does not cause problems as such following INSERT would normally come with its own INSERT_ID event. In this bug, the user had a trigger on the slave which was missing on the master, and this trigger had an INSERT which could be affected. In any case, it seems better to not leave a stray INSERT_ID hanging around in the sql thread THD indefinitely. Note that events can also be skipped from apply_event_and_update_pos(); however it is not possible in that code to skip the INSERT without also skipping the INSERT_ID event.
Diffstat (limited to 'sql/log_event.cc')
-rw-r--r--sql/log_event.cc13
1 files changed, 13 insertions, 0 deletions
diff --git a/sql/log_event.cc b/sql/log_event.cc
index 3969b6b6f4d..c3e5a831ab3 100644
--- a/sql/log_event.cc
+++ b/sql/log_event.cc
@@ -3307,6 +3307,19 @@ START SLAVE; . Query: '%s'", expected_error, thd->query());
/* If the query was not ignored, it is printed to the general log */
if (!thd->is_error() || thd->main_da.sql_errno() != ER_SLAVE_IGNORED_TABLE)
general_log_write(thd, COM_QUERY, thd->query(), thd->query_length());
+ else
+ {
+ /*
+ Bug#54201: If we skip an INSERT query that uses auto_increment, then we
+ should reset any @@INSERT_ID set by an Intvar_log_event associated with
+ the query; otherwise the @@INSERT_ID will linger until the next INSERT
+ that uses auto_increment and may affect extra triggers on the slave etc.
+
+ We reset INSERT_ID unconditionally; it is probably cheaper than
+ checking if it is necessary.
+ */
+ thd->auto_inc_intervals_forced.empty();
+ }
compare_errors: