Heikki Linnakangas <heikki.linnakan...@enterprisedb.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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
