Josh Berkus wrote: >> the behavior was the same up to the second UPDATE on Process 2, at >> which point there was no deadlock. Process 2 was able to commit, >> at which point Process 1 failed with: >> >> ERROR: could not serialize access due to concurrent update > > Does this happen immediately, not waiting 2 seconds for deadlock > checking? The deadlock checking delay never comes into play. Process 2 would never be blocked, and Process 1 would fail on the COMMIT of Process 2. Without a detailed scenario I can't comment on exact behavior, but in a serializable-only environment, with SSI enforcement of RI, you can count on only having blocking on write/write conflicts, so it would only be a cycle of those which could ever cause a deadlock. Anything where deadlocks currently occur because of SELECT FOR SHARE or SELECT FOR UPDATE would not have the same deadlock issues. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers