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 :)
[snip]
