1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-29 05:21:33 +03:00

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.
This commit is contained in:
unknown
2010-11-30 10:47:08 +01:00
parent d54f869f8c
commit e46d0aead0
4 changed files with 99 additions and 0 deletions

View File

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