diff options
author | unknown <knielsen@knielsen-hq.org> | 2010-11-30 10:47:08 +0100 |
---|---|---|
committer | unknown <knielsen@knielsen-hq.org> | 2010-11-30 10:47:08 +0100 |
commit | e46d0aead03c2c719a05c97d2ce7f94eee51a9f6 (patch) | |
tree | f4727b4ae88c68b797a3517120daf0df5aa1c59f /sql/log_event.cc | |
parent | d54f869f8c34e5bb93ab187cfc6495f9e192c259 (diff) | |
download | mariadb-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.cc | 13 |
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: |