Kevin, > In the "for what it's worth" department, I tried out the current > Serializable Snapshot Isolation (SSI) patch with this test case at > the SERIALIZABLE transaction isolation level. Rather than defining > a foreign key, I ran the queries which an SSI implementation in a > SERIALIZABLE-only environment would -- that didn't use FOR SHARE or > FOR UPDATE. Not surprisingly, 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? > If you have other examples of "user-hostile" behaviors you want to > share, I can see how they would behave under an SSI implementation. > I can almost guarantee that you won't see deadlocks, although you > will likely see more overall rollbacks in many transaction mixes. They'd be more variations of this same theme; transactions updating each other's FKs. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers