Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> However, I confess to ignorance as to the underlying
>> issues? Why is MERGE worse in this regard than, say, UPDATE?
>
> MERGE can be used to implement "upsert", where a row is updated if
> it exists and inserted if it doesn't. I don't think Kevin's patch
> will suffice for that. You don't usually want a serialization
> failure error when you run two upserts at the same time, you want
> both of them to succeed, one doing an insert and the other one
> doing an update.
The patch Dan and I are working on won't block anything that
snapshot isolation doesn't already block, so if the behavior you
want is that one is held up until the other is done with something,
it's not going to help. What it would do is detect whether two
concurrent upserts are behaving in a way that is consistent with
some serial execution of the two upserts; it would do nothing if
there was a consistent interpretation, but roll one back if each
appeared to come before the other in some respect.
All of that, of course, with the usual caveats that it would have
*no* impact unless both were run at the SERIALIZABLE isolation
level, there could be false positives, and the MERGE code might
possibly need to add a few calls to the functions added in the
serializable patch.
I hope that clarified rather than muddied the waters....
-Kevin