Chris Browne <cbbro...@acm.org> wrote: > robertmh...@gmail.com (Robert Haas) writes: >> I suspect Kevin's patch will solve it if using a sufficiently >> high transaction isolation level, but something else might be >> needed otherwise. However, I confess to ignorance as to the >> underlying issues? Why is MERGE worse in this regard than, say, >> UPDATE? > > It's worse than UPDATE because > - It could be an INSERT, if the data's new, but > - If the data's there, it becomes an UPDATE, but > - If some concurrent update has just DELETEd the data that's > there, it becomes an INSERT again, but > - Oops, that DELETE rolled bac, so it's an UPDATE again... > > Recurse as needed to make it more undecidable as to whether it's > really an INSERT or an UPDATE :-). Not to get too far into the serializable issues, but the server won't do any such recursion with the serializable patch. Each serializable transaction would have its own snapshot where the row was there or it wasn't, and would act accordingly. If they took conflicting actions on the same row, one of them might be rolled back with a serialization failure. The client is likely to want to retry the operation based on the SQLSTATE indicating serialization failure, which (as the patch stands now) could result in some head-banging if the client doesn't introduce some delay first. I have an optimization in mind (described on the Wiki page) which could help with that, but its impact on overall performance is uncertain, so I don't want to mess with that until we have more benchmarks in place for realistic loads which might use serializable isolation. So... No, it's not directly a problem on the server itself. Yes, a client can make it a problem by resubmitting failed queries "too quickly". But, we might be able to fix that with additional work. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
