Hi, Kristian! On Nov 18, Kristian Nielsen wrote: > Sergei Golubchik <[email protected]> writes: > > Kristian Nielsen, could you please review this patch? > > I guess my main question here is, did you think about why you want to) > fix this 1) in a post-GA release, 2) at all?
I wasn't sure, actually. There was a bug report. I wanted to see what it takes to fix it. But it happened out that this fix had introduced quite a few warnings in existing tests. So, I don't think this should be pushed in 10.0 in its current form. > Another point is that this patch seems to fix only a corner case of a > bigger problem? This particular patch is about non-transactional > updates. But updating a unique key can break replication just as well > on transactional tables: > > CREATE TABLE t1 (a INT PRIMARY KEY); > INSERT INTO t1 VALUES (2), (3), (4); > UPDATE t1 SET a=a-1; > > Since we do not have deferred constraints, this UPDATE will fail or > succeed depending on the order in which rows are updated. So a > statement that succeeds and gets binlogged on the master can break on > the slave if the rows are updated in a different order. Indeed. > So any reason that you fix one part of UPDATE of unique key but not > the other? Because only the first one was mentioned in the bug report. I didn't think of the second one :( Anyway, it seems that we agree not to push it into 10.0. What do you think - shall it be pushed into 10.1 or not at all? Regards, Sergei _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
