Commit 73febb3b authored by unknown's avatar unknown

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
parent ccd31e9d
......@@ -417,3 +417,17 @@ Log_name Pos Event_type Server_id End_log_pos Info
SELECT * FROM t2 ORDER BY a;
a
DROP TABLE t1,t2;
CREATE TABLE t1 (a INT);
INSERT INTO t1 VALUES (1),(1);
CREATE TABLE t2 (a INT UNIQUE) ENGINE=INNODB SELECT * FROM t1;
ERROR 23000: Duplicate entry '1' for key 'a'
INSERT INTO t1 VALUES (2);
*** the proof of the fix:
select must show that the last insert performed on the slave ***
SELECT * FROM t1;
a
1
1
2
DROP TABLE t1;
end of the tests
......@@ -234,3 +234,30 @@ SELECT * FROM t2 ORDER BY a;
connection master;
DROP TABLE t1,t2;
sync_slave_with_master;
#
# bug#35762 Failing CREATE-SELECT produces bad binlog in row mode
#
connection master;
CREATE TABLE t1 (a INT);
INSERT INTO t1 VALUES (1),(1);
--error ER_DUP_ENTRY
CREATE TABLE t2 (a INT UNIQUE) ENGINE=INNODB SELECT * FROM t1;
INSERT INTO t1 VALUES (2);
sync_slave_with_master;
# connection slave;
--echo *** the proof of the fix:
--echo select must show that the last insert performed on the slave ***
SELECT * FROM t1;
connection master;
DROP TABLE t1;
sync_slave_with_master;
--echo end of the tests
......@@ -3720,7 +3720,7 @@ void select_create::abort()
select_insert::abort();
thd->transaction.stmt.modified_non_trans_table= FALSE;
reenable_binlog(thd);
thd->binlog_flush_pending_rows_event(TRUE);
if (m_plock)
{
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment