List:Commits« Previous MessageNext Message »
From:Alfranio Correia Date:July 19 2010 9:23am
Subject:Re: bzr commit into mysql-next-mr branch (Dao-Gang.Qu:3165) WL#5440
View as plain text  
Hi Daogang,

On 07/19/2010 03:46 AM, Daogang Qu wrote:
> Alfranio Correia wrote:
>> Hi Daogang,
>>
>> Nice work.
>>
>> Patch approved.
>>
>> However I still think that the way you check if the binlog is
>> partially written may
>> cause random failures due to mismatches in the result files. Let's
>> push the patch
>> though and see what happens.
>>
>> Reasoning:
>>
>> We have the changes in the trx-cache in several logical blocks.
>> So assuming that there is a cache somewhere, the actual writting
>> to the disk will be asynchronous so you cannot predict will be
>> the content of the file.
>>
>>
>> TRX-CACHE
>> ------- ------- -------
>> | b-1 | | b-2 | | b-3 |
>> ------- ------- -------
>> |
>> V
>>
>> OS-BUFFER/DEVICE BUFFER
>> ------- ------- -------
>> | b-1 | | b-2 | | b-3 |
>> ------- ------- -------
>> |
>> V
>> PHYSICAL DISK
>> -------
>> | b-1 | ...
>> -------
>>
>> Maybe we need to augment the IO_CACHE too in order to get a deterministic
>> behavior. What do you think?
> Alternative is add more the statements with the same length data into
> the transaction.
>
> TRX-CACHE
> ------- ------- ------- --------
> | b-1 | | b-2 | | b-3 | ...... |b - 24|
> ------- ------- ------- --------
>
> What do you think?


I think this may minimize the problem but will still be non-deterministic.
So, I would assume that the test may fail and replace the code below as follows:

>>> +
>>> +-- echo # Test the non-transaction statement will be binlogged halfly
>>> +--replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR
>>> +-- replace_regex /TIMESTAMP=[0-9]*/TIMESTAMP=t/ /#[0-9]*[
>>> ]*[0-9]*:[0-9]*:[0-9]* server id [0-9]*/#server id #/
>>> /exec_time=[0-9]*/exec_time=#/ /error_code=[0-9]*/error_code=#/
>>> /end_log_pos [0-9]*/end_log_pos #/ /# at [0-9]*/# at #/ /Xid =
>>> [0-9]*/Xid = #/ /thread_id=[0-9]*/thread_id=#/ /table id [0-9]*/table
>>> id #/ /mapped to number [0-9]*/mapped to number #/ /server v [^
>>> ]*/server v #.##.##/ /Start: binlog v [0-9]*/Start: binlog v#/
>>> /created [0-9]*[ ]*[0-9]*:[0-9]*:[0-9]* at startup/created # #:#:# at
>>> startup/
>>> +--exec $MYSQL_BINLOG --force-if-open $MYSQLD_DATADIR/$master_binlog
>>> 1> $MYSQLD_DATADIR/$master_binlog.result


1. Verify if the last entry is not a "commit".
2. If it is the test failed as expected and you do what you already do.
3. Otherwise, the test did not fail and this situation is ok too.

Cheers.
Thread
bzr commit into mysql-next-mr branch (Dao-Gang.Qu:3165) WL#5440Dao-Gang.Qu15 Jul
  • Re: bzr commit into mysql-next-mr branch (Dao-Gang.Qu:3165) WL#5440Alfranio Correia16 Jul
    • Re: bzr commit into mysql-next-mr branch (Dao-Gang.Qu:3165) WL#5440Daogang Qu19 Jul
      • Re: bzr commit into mysql-next-mr branch (Dao-Gang.Qu:3165) WL#5440Alfranio Correia19 Jul
  • Re: bzr commit into mysql-next-mr branch (Dao-Gang.Qu:3165) WL#5440Libing Song18 Jul
    • Re: bzr commit into mysql-next-mr branch (Dao-Gang.Qu:3165) WL#5440Daogang Qu19 Jul
      • Re: bzr commit into mysql-next-mr branch (Dao-Gang.Qu:3165) WL#5440Libing Song19 Jul
        • Re: bzr commit into mysql-next-mr branch (Dao-Gang.Qu:3165) WL#5440Daogang Qu19 Jul