He Zhenxing wrote:
> Alfranio Correia wrote:
>
>> He Zhenxing wrote:
>>
>>> Hi, Alfranio,
>>>
>>> I think the patch is OK, there are some minor comments in line.
>>>
>>> Alfranio Correia:
>>>
>>>
>>>> #At
> file:///home/acorreia/workspace.sun/repository.mysql/bzrwork/bug-28976/mysql-5.1-bugteam/
> based on revid:martin.hansson@stripped
>>>>
>>>> 2972 Alfranio Correia 2009-07-09
>>>> BUG#28976 Mixing trans and non-trans tables in one transaction
> results in incorrect
>>>> binlog
>>>>
>>>> Mixing transactional and non-transactional tables on behalf of a
> transaction may
>>>> lead to inconsistencies among masters and slaves. The problem stems
> from the fact
>>>> that although modifications done to non-transactional tables on
> behalf of a
>>>> transaction become immediately visible to the other connections it
> does not
>>>> immediately gets to the binary log and therefore consistency is
> broken.
>>>>
>>>> After the WL#2687, it will be safe to use either the MIXED or ROW
> mode to do such
>>>> mix. Changes to non-transactional tables will immediately get to
> the binary log
>>>> as rows. Under the STATEMENT mode, however, changing
> non-transactional tables
>>>> before transactional ones is the only possible safe mix. This
> happen because it
>>>> is as if such changes had not been executed on the behalf of a
> transaction.
>>>> On the other hand, other combinations may hide a causal dependency,
> thus making
>>>> impossible to immediately write statements with non-transactional
> tables to the
>>>> binary log.
>>>>
>>>> This patch guarantees that a mix under the STATEMENT mode is
> handled as follows:
>>>>
>>>> 1) "B T T C" generates the "B T T C" entries in the binary log.
>>>>
>>>> 2) "B T T R" generates an "empty" entry in the binary log.
>>>>
>>>> 2) "B T N C" generates the "B T N C" entries in the binary log.
>>>>
>>>> 3) "B T N R" generates the "B T N R" entries in the binary log.
>>>>
>>>> 4) "T" generates the "B T C" entries in the binary log.
>>>>
>>>> 5) "T" with error generates an "empty" entry in the binary log.
>>>>
>>>> 6) "N" generates the "N" entry in the binary log.
>>>>
>>>> 7) "N" generates an empty entry if the error happens in the first
> tuple.
>>>> Otherwise, generates the "N" entry in the binary log.
>>>>
>>>> 8) "M" generates the "B M C" entries in the binary log.
>>>>
>>>> 10) "M" with error generates the "B M C" entries in the binary
> log.
>>>>
>>>> 11) "B N N T C" generates the "N N B T C" entries in the binary
> log.
>>>>
>>>> 12) "B N N T R" generates the "N N B T R" entries in the binary
> log.
>>>>
>>>> 13) "B N N C" generates the "N N" entries in the binary log.
>>>>
>>>> 14) "B N N R" generates the "N N" entries in the binary log.
>>>>
>>>> 15) "B M T C" generates the "B M T C" entries in the binary log.
>>>>
>>>> 16) "B M T R" generates the "B M T R" entries in the binary log.
>>>>
>>>>
>>>>
>>> I think the above is a bit too much for this bug,
>>>
>> I don't agree with this. It is better to have a good test case that
>> addresses (or tries to) all possible combinations of statements.
>>
>>
>
> I do agree with you that it's good to do complete test and put these
> information in the test file.
>
--------------
> What I mean is that I personally think that it's not very necessary to
> put all these in the commit message. But it's up to you :)
>
--------------
I did not understand you in the first message. But I think
you are on the same page because I removed such information
from the commit message. I did not like either :)
Cheers.
> [snip]
>
>
