Bruce Momjian wrote: > The fundamental behavior above is that the S1 transaction is adding > _and_ removing rows from the S2 query's result set; S2 is seeing the > pre-query values that don't match its criteria and ignoring them and > blocking on a later row that does match its criteria. Once S1 commits, > the new row does not match its criteria and it skips it, making the > SELECT FOR UPDATE return zero rows, and the S2 UPDATE do nothing. > > Serializable mode does prevent the problem outlined above.
To clarify, serializable throws an error, as expected. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
