mariadb/mysql-test/suite/rpl/t/rpl_row_trunc_temp.test
unknown a2ed682967 Bug #48350 truncate temporary table crashes replication
In RBR, All statements operating on temporary tables should not be binlogged.
Despite this fact, after executing 'TRUNCATE... ' on a temporary table, 
the command is still logged, even if in row-based mode. Consequently, this raises
problems in the slave as the table may not exist, resulting in an
execution failure. Ultimately, this causes the slave to report
an error and abort.

After this patch, 'TRUNCATE ...' statement on a temporary table will not be
binlogged in RBR.
2009-11-22 13:10:33 +08:00

35 lines
868 B
Text

#
# Bug#48350 truncate temporary table crashes replication
#
# All statements operating on temporary tables should not be binlogged in RBR.
# However, before fix of bug#48350, 'TRUNCATE ...' statement on a temporary
# table was binlogged in RBR.
#
--source include/master-slave.inc
--source include/have_binlog_format_row.inc
#This statement is not binlogged in RBR.
CREATE TEMPORARY TABLE t1(c1 INTEGER);
CREATE TABLE t2(c1 INTEGER);
sync_slave_with_master;
CREATE TABLE t1(c1 INTEGER);
INSERT INTO t1 VALUES(1), (2);
INSERT INTO t2 VALUES(1), (2);
SELECT * FROM t1;
SELECT * FROM t2;
connection master;
TRUNCATE t1;
TRUNCATE t2;
sync_slave_with_master;
# t1 will have nothing, if 'TRUNCATE t1' has been replicate from master to
# slave.
SELECT * FROM t1;
SELECT * FROM t2;
DROP TABLE t1;
connection master;
DROP TABLE t2;
--source include/master-slave-end.inc