~ubuntu-branches/ubuntu/maverick/mysql-5.1/maverick-proposed

« back to all changes in this revision

Viewing changes to mysql-test/suite/rpl/t/rpl_relayspace.test

  • Committer: Package Import Robot
  • Author(s): Marc Deslauriers
  • Date: 2012-02-22 14:16:05 UTC
  • mto: This revision was merged to the branch mainline in revision 20.
  • Revision ID: package-import@ubuntu.com-20120222141605-nxlu9yzc6attylc2
Tags: upstream-5.1.61
ImportĀ upstreamĀ versionĀ 5.1.61

Show diffs side-by-side

added added

removed removed

Lines of Context:
2
2
# to force the deadlock after one event.
3
3
 
4
4
source include/master-slave.inc;
 
5
--let $master_log_file= query_get_value(SHOW MASTER STATUS, File, 1)
5
6
connection slave;
6
 
stop slave;
 
7
--source include/stop_slave.inc
7
8
connection master;
8
9
# This will generate a master's binlog > 10 bytes
9
10
create table t1 (a int);
19
20
source include/wait_for_slave_param.inc;
20
21
 
21
22
# A bug caused the I/O thread to refuse stopping.
22
 
stop slave io_thread;
 
23
--source include/stop_slave_io.inc
23
24
reset slave;
24
 
start slave;
25
 
# The I/O thread stops filling the relay log when
26
 
# it's >10b. And the SQL thread cannot purge this relay log
27
 
# as purge is done only when the SQL thread switches to another
28
 
# relay log, which does not exist here.
29
 
# So we should have a deadlock.
30
 
# if it is not resolved automatically we'll detect
31
 
# it with master_pos_wait that waits for farther than 1Ob;
32
 
# it will timeout after 10 seconds;
33
 
# also the slave will probably not cooperate to shutdown
34
 
# (as 2 threads are locked)
35
 
select master_pos_wait('master-bin.001',200,6)=-1;
 
25
--source include/start_slave.inc
 
26
 
 
27
# The I/O thread stops filling the relay log when it's >10b. And the
 
28
# SQL thread cannot purge this relay log as purge is done only when
 
29
# the SQL thread switches to another relay log, which does not exist
 
30
# here.  So we should have a deadlock.  If it is not resolved
 
31
# automatically we'll detect it with master_pos_wait that waits for
 
32
# farther than 1Ob; it will timeout after 300 seconds (which is inline
 
33
# with the default used for sync_slave_with_master and will protect us
 
34
# against slow test envs); also the slave will probably not cooperate
 
35
# to shutdown (as 2 threads are locked)
 
36
--let $outcome= `SELECT MASTER_POS_WAIT('$master_log_file',200,300) AS mpw;`
 
37
 
 
38
# master_pos_wait returns:
 
39
#
 
40
# * >= 0, the number of events the slave had to wait to advance to the
 
41
#         position
 
42
#
 
43
# * -1,   if there was a timeout
 
44
#
 
45
# * NULL, if an error occurred, or the SQL thread was not started,
 
46
#         slave master info is not initialized, the arguments are incorrect
 
47
--let $assert_text= Assert that master_pos_wait does not timeout nor it returns NULL
 
48
--let $assert_cond= $outcome IS NOT NULL AND $outcome <> -1
 
49
--source include/assert.inc
36
50
 
37
51
# End of 4.1 tests
 
52
--source include/rpl_end.inc