Re: determine snapshot after obtaining locks for first statement - Mailing list pgsql-hackers

From Tom Lane
Subject Re: determine snapshot after obtaining locks for first statement
Date
Msg-id 4120.1261071598@sss.pgh.pa.us
Whole thread Raw
In response to Re: determine snapshot after obtaining locks for first statement  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: determine snapshot after obtaining locks for first statement  (Greg Stark <gsstark@mit.edu>)
Re: determine snapshot after obtaining locks for first statement  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Tom Lane <tgl@sss.pgh.pa.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


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: COPY IN as SELECT target
Next
From: Robert Haas
Date:
Subject: Re: COPY IN as SELECT target