On Sun, Oct 24, 2010 at 7:11 PM, Greg Stark <gsst...@mit.edu> wrote: > On Sun, Oct 24, 2010 at 2:50 AM, Martijn van Oosterhout > <klep...@svana.org> wrote: >> Can we please not get MERGE hung up on trying to make it atomic. The >> standard requires no such thing and there are plenty of uses of MERGE >> that don't involve high concurrency updates of the same row by >> different processes. If we want an atomic UPSERT, make that a seperate >> command, MERGE without atomicity is useful enough already. > > Really? I don't really see any point in a non-atomic MERGE. Nor in a > non-atomic UPDATE or INSERT or any other operation. The A in ACID is > as important as any other letter.
I think we're really discussing the "I" in ACID, not the "A". There's no question that the MERGE transaction will either commit or fail. What we're talking about is what happens when there are concurrent table modifications in progress; and the answer is that you might get serialization anomalies. But we have serialization anomalies without MERGE, too - see the discussions around Kevin Grittner's SSI patch which, come to think of it, might be useful for this case, too. I posted an example upthread which I think demonstrates very clearly that MERGE will result in unavoidable serialization failures - so if the standard is that we mustn't have any serialization failures then the standard can never be met. The best we can hope for is that we'll detect them and roll back if they occur, rather than going on to commit but perhaps with some anomaly. And I'm pretty sure that's what KG's SSI patch is going to give us. So I'm not sure there's really anything to get worked up about here in terms of concurrency issues. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
