BUG#11746302: 25228: RPL_RELAYSPACE.TEST FAILS ON POWERMACG5,

              VM-WIN2003-32-A, SLES10-IA64-A 
      
The test case waits for master_pos_wait not to timeout, which
means that the deadlock between SQL and IO threads was 
succesfully and automatically dealt with.
      
However, very rarely, master_pos_wait reports a timeout. This
happens because the time set for master_pos_wait to wait was
too small (6 seconds). On slow test env this could be a 
problem.
      
We fix this by setting the timeout inline with the one used
in sync_slave_with_master (300 seconds). In addition we 
refactored the test case and refined some comments.

mysql-test/suite/rpl/r/rpl_relayspace.result

 include/master-slave.inc
 [connection master]
-stop slave;
+include/stop_slave.inc
 create table t1 (a int);
 drop table t1;
 create table t1 (a int);
@@ -8,10 +8,8 @@ drop table t1;
 reset slave;
 start slave io_thread;
 include/wait_for_slave_param.inc [Slave_IO_State]
-stop slave io_thread;
+include/stop_slave_io.inc
 reset slave;
-start slave;
-select master_pos_wait('master-bin.001',200,6)=-1;
-master_pos_wait('master-bin.001',200,6)=-1
-0
+include/start_slave.inc
+include/assert.inc [Assert that master_pos_wait does not timeout nor it returns NULL]
 include/rpl_end.inc

mysql-test/suite/rpl/t/rpl_relayspace.test

@@ -2,8 +2,9 @@
 # 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;
-stop slave;
+--source include/stop_slave.inc
 connection master;
 # This will generate a master's binlog > 10 bytes
 create table t1 (a int);
@@ -19,20 +20,33 @@ let $slave_param_value= Waiting for the slave SQL thread to free enough relay lo
 source include/wait_for_slave_param.inc;
 
 # A bug caused the I/O thread to refuse stopping.
-stop slave io_thread;
+--source include/stop_slave_io.inc
 reset slave;
-start slave;
-# 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 10 seconds;
-# also the slave will probably not cooperate to shutdown
-# (as 2 threads are locked)
-select master_pos_wait('master-bin.001',200,6)=-1;
+--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