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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +