mirror of
https://github.com/MariaDB/server.git
synced 2025-01-19 13:32:33 +01:00
366fd92e8d
More messages. Testcase for bug 651. client/mysqltest.c: More explicit error message if MASTER_POS_WAIT() returns NULL. mysql-test/r/rpl_loaddata.result: result update mysql-test/r/rpl_master_pos_wait.result: result update mysql-test/t/rpl000001.test: sync_with_master (=MASTER_POS_WAIT()) was called when we could expect the SQL slave thread had stopped. As I yesterday changed code so that "SQL thread stops => MASTER_POS_WAIT() returns NULL immediately" (bugfix), sync_with_master received NULL (on build.mysql.com, not on my machine; this is a question of milliseconds, if the slave server will process MASTER_POS_WAIT() before or after the slave SQL thread has stopped), and in mysqltest.c, sync_with_master complained that it could not sync. So I just remove this sync_with_master, which does not make sense anymore: we just wait for the slave SQL thread to stop. mysql-test/t/rpl_loaddata.test: Discovered we had wait_for_slave_to_stop, so used it as it automates things. mysql-test/t/rpl_master_pos_wait.test: Discovered we had 'send' to send a query without waiting for the resultn so could had a testcase for bug 651. Shorter timeouts as there is no risk the position is reached. sql/slave.cc: A longer DBUG_PRINT.
13 lines
358 B
Text
13 lines
358 B
Text
slave stop;
|
|
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
|
|
reset master;
|
|
reset slave;
|
|
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
|
|
slave start;
|
|
select master_pos_wait('master-bin.999999',0,2);
|
|
master_pos_wait('master-bin.999999',0,2)
|
|
-1
|
|
select master_pos_wait('master-bin.999999',0);
|
|
stop slave sql_thread;
|
|
master_pos_wait('master-bin.999999',0)
|
|
NULL
|