A trick (a useless update) to force the slave to wait for TWO rotate events

before stopping. This is to make the test's result predictable (depending
on the machine the results could formerly be slightly different, though
everything is sane in the code; it's not a bug).


mysql-test/r/rpl_log.result:
  result update

mysql-test/r/rpl_log.result

@@ -36,6 +36,8 @@ show binlog events from 79 limit 2,1;
 Log_name	Pos	Event_type	Server_id	Orig_log_pos	Info
 master-bin.001	200	Query	1	200	use test; insert into t1 values (NULL)
 flush logs;
+create table t5 (a int);
+drop table t5;
 slave start;
 flush logs;
 slave stop;
@@ -56,9 +58,11 @@ master-bin.001	1079	Query	1	1079	use test; drop table t1
 master-bin.001	1127	Rotate	1	1127	master-bin.002;pos=4
 show binlog events in 'master-bin.002';
 Log_name	Pos	Event_type	Server_id	Orig_log_pos	Info
-master-bin.002	4	Query	1	4	use test; create table t1 (n int)
-master-bin.002	62	Query	1	62	use test; insert into t1 values (1)
-master-bin.002	122	Query	1	122	use test; drop table t1
+master-bin.002	4	Query	1	4	use test; create table t5 (a int)
+master-bin.002	62	Query	1	62	use test; drop table t5
+master-bin.002	110	Query	1	110	use test; create table t1 (n int)
+master-bin.002	168	Query	1	168	use test; insert into t1 values (1)
+master-bin.002	228	Query	1	228	use test; drop table t1
 show master logs;
 Log_name
 master-bin.001
@@ -79,14 +83,16 @@ slave-bin.001	311	Query	1	311	use test; create table t1 (word char(20) not null)
 slave-bin.001	386	Create_file	1	386	db=test;table=t1;file_id=1;block_len=581
 slave-bin.001	1065	Exec_load	1	1056	;file_id=1
 slave-bin.001	1088	Query	1	1079	use test; drop table t1
-slave-bin.001	1136	Rotate	2	1136	slave-bin.002;pos=4
+slave-bin.001	1136	Query	1	4	use test; create table t5 (a int)
+slave-bin.001	1194	Query	1	62	use test; drop table t5
+slave-bin.001	1242	Rotate	2	1242	slave-bin.002;pos=4
 show binlog events in 'slave-bin.002' from 4;
 Log_name	Pos	Event_type	Server_id	Orig_log_pos	Info
-slave-bin.002	4	Query	1	4	use test; create table t1 (n int)
-slave-bin.002	62	Query	1	62	use test; insert into t1 values (1)
-slave-bin.002	122	Query	1	122	use test; drop table t1
+slave-bin.002	4	Query	1	110	use test; create table t1 (n int)
+slave-bin.002	62	Query	1	168	use test; insert into t1 values (1)
+slave-bin.002	122	Query	1	228	use test; drop table t1
 show slave status;
 Master_Host	Master_User	Master_Port	Connect_retry	Master_Log_File	Read_Master_Log_Pos	Relay_Log_File	Relay_Log_Pos	Relay_Master_Log_File	Slave_IO_Running	Slave_SQL_Running	Replicate_do_db	Replicate_ignore_db	Last_errno	Last_error	Skip_counter	Exec_master_log_pos	Relay_log_space
-127.0.0.1	root	MASTER_PORT	1	master-bin.002	170	slave-relay-bin.002	1457	master-bin.002	Yes	Yes			0		0	170	1461
+127.0.0.1	root	MASTER_PORT	1	master-bin.002	276	slave-relay-bin.002	1522	master-bin.002	Yes	Yes			0		0	276	1526
 show binlog events in 'slave-bin.005' from 4;
 Error when executing command SHOW BINLOG EVENTS: Could not find target log

mysql-test/t/rpl_log.test

@@ -22,10 +22,32 @@ show binlog events from 79 limit 2;
 show binlog events from 79 limit 2,1;
 flush logs;
 
+# We need an extra update before doing save_master_pos.
+# Otherwise, an unlikely scenario may occur:
+# * When the master's binlog_dump thread reads the end of master-bin.001,
+# it send the rotate event which is at this end, plus a fake rotate event
+# because it's starting to read a new binlog.
+# save_master_pos will record the position of the first of the two rotate
+# (because the fake one is not in the master's binlog anyway).
+# * Later the slave waits for the position of the first rotate event,
+# and it may quickly stop (in 'slave stop') without having received the fake
+# one.
+# So, depending on a few milliseconds, we end up with 2 rotate events in the
+# relay log or one, which influences the output of SHOW SLAVE STATUS, making
+# it not predictable and causing random test failures.
+# To make it predictable, we do a useless update now, but which has the interest
+# of making the slave catch both rotate events.
+
+create table t5 (a int);
+drop table t5;
+
 # Sync slave and force it to start on another binary log
 
 save_master_pos;
 connection slave;
+# Note that the above 'slave start' will cause a 3rd rotate event (a fake one)
+# to go into the relay log (the master always sends a fake one when replication
+# starts). 
 slave start;
 sync_with_master;
 flush logs;