WordPress

# The slave is started with relay_log_space_limit=10 bytes,
# to force the deadlock after one event.

source include/master-slave.inc;
--let $master_log_file= query_get_value(SHOW MASTER STATUS, File, 1)
connection slave;
--source include/stop_slave.inc
connection master;
# This will generate a master's binlog > 10 bytes
create table t1 (a int);
drop table t1;
create table t1 (a int);
drop table t1;
connection slave;
reset slave;
start slave io_thread;
# Give the I/O thread time to block.
let $slave_param= Slave_IO_State;
let $slave_param_value= Waiting for the slave SQL thread to free enough relay log space;
source include/wait_for_slave_param.inc;

# A bug caused the I/O thread to refuse stopping.
--source include/stop_slave_io.inc
reset slave;
--source include/start_slave.inc

# The I/O thread stops filling the relay log when it's >10b. And the
# SQL thread cannot purge this relay log as purge is done only when
# the SQL thread switches to another relay log, which does not exist
# here.  So we should have a deadlock.  If it is not resolved
# automatically we'll detect it with master_pos_wait that waits for
# farther than 1Ob; it will timeout after 300 seconds (which is inline
# with the default used for sync_slave_with_master and will protect us
# against slow test envs); also the slave will probably not cooperate
# to shutdown (as 2 threads are locked)
--let $outcome= `SELECT MASTER_POS_WAIT('$master_log_file',200,300) AS mpw;`

# master_pos_wait returns:
#
# * >= 0, the number of events the slave had to wait to advance to the
#         position
#
# * -1,   if there was a timeout
#
# * NULL, if an error occurred, or the SQL thread was not started,
#         slave master info is not initialized, the arguments are incorrect
--let $assert_text= Assert that master_pos_wait does not timeout nor it returns NULL
--let $assert_cond= $outcome IS NOT NULL AND $outcome <> -1
--source include/assert.inc

# End of 4.1 tests
--source include/rpl_end.inc