maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

Hi, Kristian!

On Nov 18, Kristian Nielsen wrote:
> Sergei Golubchik <serg@xxxxxxxxxxx> 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