Robert Haas <robertmh...@gmail.com> wrote: > Users hate having to do explicit locking (especially users whose > names rhyme with Bevin Bittner) :-) Before you decide to taunt me again, I guess I should point out a few things here. Should SSI and MERGE both make it into 9.1, there's every reason to believe that running just about any DML, including MERGE, at REPEATABLE READ would generate the same behavior which running at REPEATABLE READ or SERIALIZABLE does now. If MERGE is susceptible to such anomalies as testing for the presence of a row and then trying to UPDATE it if found, only to update zero rows because it was concurrently deleted, SERIALIZABLE would prevent that with a serialization failure. I'd kind of expect that already with a write-write conflict, but if that isn't happening, the SSI patch should help. Well, help prevent anomalies -- if you want it to work out how to continue without rolling back it won't help at all. The fact that SSI introduces predicate locking may ultimately allow MERGE to do something more clever in terms of UPSERT logic, but I *REALLY* think it's too late in the release cycle to start looking at that. Predicate locking for SSI was done exactly as was most useful for SSI, on the basis (generally popular on this list) that trying to generalize something with only one use case is doomed to failure. Trying to bend it in an additional direction this late in the release would pretty much ensure that neither MERGE nor SSI could make it in. On the other hand, if we put SSI in with predicate locking more or less as it is, and put MERGE in with more primitive concurrency control, I fully expect that someone could figure out how to tease apart SSI and its predicate locking during the next release cycle, so that the predicate locking was more generally useful. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
