Bug #35762 Failing CREATE-SELECT steels Table map of the following query
Among two claimed artifacts the critical one is in that the Table map of a query following the failing with a duplicate key error CREATE-SELECT is skipped from instantionating (and thus binlogging). That leads to sending a "chopped" group of the data row-events without the table map head to the slave. The slave can not apply the only data row events. It's not easy to force the slave to react with an error in such a case (the second complaint on the bug report), because the lack of a table Rows_log_event::do_apply_event the data row event handler is a common situation which normally designates the event has to be filtered out basing on the repliation do/ingore rules decision. Fixed: table map creating and binlogging is restored via deploying the standard cleanup call in select_create::abort(). No error is reported if by chance the table map was not been binlogged. Leaving this out to resolve with considering how to combine the do/ingore rules with the situation when erronoulsy the Table_map is not written to binlog. mysql-test/suite/rpl/r/rpl_row_create_table.result: results changed mysql-test/suite/rpl/t/rpl_row_create_table.test: regression test for the bug sql/sql_insert.cc: adding resetting of thd binlogging state that was missed for the particular case of failing CREATE..SELECT
Showing
Please register or sign in to comment