mariadb/mysql-test/suite/binlog/r/binlog_tmp_table.result
Luis Soares cdb37d69af BUG#53101: binlog.binlog_tmp_table fails on sol10 sparc64 max in
parallel mode
      
The failure has nothing to do with parallel, but rather on the
order the tests are executed. In this case, the test
binlog_tmp_table (lets call it test2) was not ensuring that the
binary logs would be reset when it started. Later the test issues
a mysqlbinlog .../master-bin.000002 | mysql ... If the test that
was executed before this one (lets call it test1) had issued a
flush logs, then the file in use in test1 (master-bin.000002)
would not actually match the one that was expected. Eventually,
this would cause the statements logged in test1 to be replayed,
instead of the ones logged in the beginning of test2.
    
We fix this by:
  1. adding RESET MASTER to the beginning of binlog_tmp_table
  2. setting dynamically the file to use in binlog_tmp_table
     
Only #1 was needed, but the two make the tests cases more robust.
2010-04-27 12:25:55 +01:00

42 lines
877 B
Text

RESET MASTER;
create table foo (a int);
flush logs;
create temporary table tmp1_foo like foo;
create temporary table tmp2_foo (a int);
insert into tmp1_foo values (1), (2), (3), (4);
replace into tmp2_foo values (1), (2), (3), (4);
update tmp1_foo set a=2*a-1;
update tmp2_foo set a=2*a;
delete from tmp1_foo where a < 5;
delete from tmp2_foo where a < 5;
insert into foo select * from tmp1_foo;
insert into foo select * from tmp2_foo;
truncate table tmp1_foo;
truncate table tmp2_foo;
flush logs;
select * from foo;
a
5
7
6
8
drop table foo;
create table foo (a int);
select * from foo;
a
5
7
6
8
drop table foo;
RESET MASTER;
create database b51226;
use b51226;
create temporary table t1(i int);
use b51226;
create temporary table t1(i int);
create temporary table t1(i int);
ERROR 42S01: Table 't1' already exists
insert into t1 values(1);
DROP DATABASE b51226;
FLUSH LOGS;