mariadb/mysql-test/t/rpl_commit_after_flush.test

source include/master-slave.inc;
source include/have_innodb.inc;
create table t1 (a int) engine=innodb;
begin;
insert into t1 values(1);
flush tables with read lock;
commit;
save_master_pos;
connection slave;
sync_with_master;
# cleanup
connection master;
unlock tables;
drop table t1;
save_master_pos;
connection slave;
sync_with_master;
Fix for BUG#5949 "error code 1223 in binlog when using innobackup": when one connection had done FLUSH TABLES WITH READ LOCK, some updates, and then COMMIT, it was accepted but my_error() was called and so, while client got no error, error was logged in binlog. We now don't call my_error() in this case; we assume the connection know what it does. This problem was specific to 4.0.21. The change is needed to make replication work with existing versions of innobackup. 2004-10-11 11:01:38 +02:00			`source include/master-slave.inc;`
			`source include/have_innodb.inc;`
After merge fixes 2004-10-20 16:28:40 +02:00			`create table t1 (a int) engine=innodb;`
Fix for BUG#5949 "error code 1223 in binlog when using innobackup": when one connection had done FLUSH TABLES WITH READ LOCK, some updates, and then COMMIT, it was accepted but my_error() was called and so, while client got no error, error was logged in binlog. We now don't call my_error() in this case; we assume the connection know what it does. This problem was specific to 4.0.21. The change is needed to make replication work with existing versions of innobackup. 2004-10-11 11:01:38 +02:00			`begin;`
			`insert into t1 values(1);`
			`flush tables with read lock;`
			`commit;`
			`save_master_pos;`
			`connection slave;`
			`sync_with_master;`
			`# cleanup`
			`connection master;`
			`unlock tables;`
			`drop table t1;`
			`save_master_pos;`
			`connection slave;`
			`sync_with_master;`