Re: determine snapshot after obtaining locks for first statement

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> http://developer.postgresql.org/pgdocs/postgres/transaction-iso.html#XACT-READ-COMMITTED

> I don't know how many times I've read that page (many), yet I never
> properly comprehended the impact of that part. I think the last bit
> I quoted above is somewhat misleading, in that it implies that the
> issue is limited to complex search conditions. In the failing case
> I showed in this thread, the search conditions involved are
> comparisons for equality of an integer literal to the one-column
> integer primary key. It seems like any join or subquery which
> references a table is vulnerable, yes?

Well, it would all depend on what you're trying to do. Typical
single-row UPDATE commands aren't really affected by this problem,
and in fact the behavior is pretty much exactly what they want as
long as the WHERE conditions don't involve columns that are being
changed.

Maybe we should replace the bit about "complex search conditions"
with something about referencing multiple rows to perform one update.
I'm not very sure what a clearer explanation would look like though.

regards, tom lane