maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

Hi, Kristian!

(this is just a reply to this your email, I'm going to reply to the
review separately)

On Nov 18, Kristian Nielsen wrote:
> By the way, it would be a lot better if we could do it so that the statement
> is only marked unsafe if it modifies more than one row. I would guess that
> UPDATE of a unique key are by far most common with single-row updates, and
> such updates should be safe. So it would be great if they did not get affected
> and cause warnings in the error log.

I had a different idea - only issue this warning when an actual unique
conflict occurs. It can be easily combined with yours - only issue a
warning if a unique conflict occurs and some rows were already updated.

> But I am not sure if that can be achieved easily. It is probably not ok to
> delay the decide_logging_format() call until we actually see a second row
> being updated - at that point it is too late to switch to row-based
> binlogging, we would lose the update to the first row, I think.

Yes, in this case I though it'll need to switch to RBR (from MIXED) at
the beginning - like in my current patch - but only issue a warning if
there was a conflict.

But this behavior is not consistent with existing implementations. For
example, INSERT IGNORE and UPDATE IGNORE always issue an unsafe warning,
not only when an actual conflict was ignored.

For consistency all these cases would need to be fixed to follow the new
semantics.

Regards,
Sergei