![](https://secure.gravatar.com/avatar/39b623a1559cf9c69ac3d9d4fb44e7fe.jpg?s=120&d=mm&r=g)
Hi, Kristian! On Nov 18, Kristian Nielsen wrote:
Sergei Golubchik
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