Serge,
> Andrei Elkin wrote:
>> Serge, hello.
>>
>> Could you please start with the problem desciption?
>>
>> I think it is
>>
>> Problem: using sleep() in the test cased its indeterministic execution.
>>
>>> #At file:///home/ksm/sun/repo/mysql-5.0-rpl-bug22442/
>>>
>>> 2613 Serge Kozlov 2008-08-25
>>> Bug#22442:
>>> 1. Added vertical output for SHOW SLAVE STATUS and waiting
> starting/stopping slave instead sleep.
>>> 2. Updated the result file.
>>
>> ok
>>
>>> modified:
>>> mysql-test/r/rpl_flush_log_loop.result
>>> mysql-test/t/rpl_flush_log_loop.test
>>>
>>> === modified file 'mysql-test/r/rpl_flush_log_loop.result'
>>> --- a/mysql-test/r/rpl_flush_log_loop.result 2007-10-10 07:21:11 +0000
>>> +++ b/mysql-test/r/rpl_flush_log_loop.result 2008-08-25 09:23:15 +0000
>>> @@ -20,5 +20,36 @@ master_password='',master_port=SLAVE_POR
>>> start slave;
>>> flush logs;
>>> show slave status;
>>>
> -Slave_IO_State 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 Replicate_Do_Table Replicate_Ignore_Table Replicate_Wild_Do_Table Replicate_Wild_Ignore_Table Last_Errno Last_Error Skip_Counter Exec_Master_Log_Pos Relay_Log_Space Until_Condition Until_Log_File Until_Log_Pos Master_SSL_Allowed Master_SSL_CA_File Master_SSL_CA_Path Master_SSL_Cert Master_SSL_Cipher Master_SSL_Key Seconds_Behind_Master
>>>
> -# 127.0.0.1 root SLAVE_PORT 60 slave-bin.000001 208 # # slave-bin.000001 Yes Yes 0 0 208 # None 0 No #
>>> +Slave_IO_State #
>>> +Master_Host 127.0.0.1
>>> +Master_User root
>>> +Master_Port 9306
>>> +Connect_Retry 1
>>> +Master_Log_File master-bin.000001
>>> +Read_Master_Log_Pos 98
>>> +Relay_Log_File #
>>> +Relay_Log_Pos #
>>> +Relay_Master_Log_File master-bin.000001
>>> +Slave_IO_Running Yes
>>> +Slave_SQL_Running Yes
>>> +Replicate_Do_DB
>>> +Replicate_Ignore_DB
>>> +Replicate_Do_Table
>>> +Replicate_Ignore_Table #
>>> +Replicate_Wild_Do_Table
>>> +Replicate_Wild_Ignore_Table
>>> +Last_Errno 0
>>> +Last_Error
>>> +Skip_Counter 0
>>> +Exec_Master_Log_Pos 98
>>> +Relay_Log_Space #
>>> +Until_Condition None
>>> +Until_Log_File
>>> +Until_Log_Pos 0
>>> +Master_SSL_Allowed No
>>> +Master_SSL_CA_File
>>> +Master_SSL_CA_Path
>>> +Master_SSL_Cert
>>> +Master_SSL_Cipher
>>> +Master_SSL_Key
>>> +Seconds_Behind_Master #
>>>
>>> === modified file 'mysql-test/t/rpl_flush_log_loop.test'
>>> --- a/mysql-test/t/rpl_flush_log_loop.test 2007-10-10 07:21:11 +0000
>>> +++ b/mysql-test/t/rpl_flush_log_loop.test 2008-08-25 09:23:15 +0000
>>> @@ -8,20 +8,22 @@ show variables like 'relay_log%';
>>> connection slave;
>>> stop slave;
>>
>
> Am I correct that we don't need to wait stop and because in fact next
> statement is start slave and we have issues here?
right, no problem to execute
stop slave; start slave
without waiting for the first stop.
>
>> There is no need for waiting at all. Notice, that when `stop slave'
>> returns the status' are
>> Slave_IO_Running NO
>> Slave_SQL_Running NO
>> by the algorithm of `stop slave'.
>> Hence, wait_for_slave_to_stop is never needed if the only point is to
>> ensure the running status' are NO.
>>
>>> +--source include/wait_for_slave_to_stop.inc
>>> --replace_result $MASTER_MYPORT MASTER_PORT
>>> eval change master to master_host='127.0.0.1',master_user='root',
>>> master_password='',master_port=$MASTER_MYPORT;
>>> start slave;
>>
>>> +--source include/wait_for_slave_to_start.inc
>>
>> This synchronization is unnecessary as well according to logics of
>> the test. Notice, that there is a difference with `stop slave' case in
>> that Slave_IO_Running value is uncertain by return from `start
>> slave', Slave_SQL_Running is YES.
>> The uncertainly is due to the fact that Slave_IO_Running is
>> three-value set. Returning ack to the client happens when IO thread
>> has started but not yet connected to the master side.
>> And only upon connnecting Slave_IO_Running gets YES.
>>
>>> connection master;
>>> --replace_result $SLAVE_MYPORT SLAVE_PORT
>>> eval change master to master_host='127.0.0.1',master_user='root',
>>> master_password='',master_port=$SLAVE_MYPORT;
>>> start slave;
>>> -sleep 5;
>>
>>> +--source include/wait_for_slave_to_start.inc
>>
>> ok.
>>
>>> flush logs;
>>
>>> sleep 5;
>>
>> what shall we do with this sleep?
>
> The good question ... seems here we wait flush logs
>
I think it is to wait for rotation of the relay log as the following
command is
show slave status;
Hence, why not to wait for the expected value of the relay log file
with wait_for_slave_param ?
A
