Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> the behavior under READ COMMITTED could be astonishing in certain
>> circumstances as it breaks atomicity:
>
> Yup. That is stated fairly clearly already in the description of
> READ COMMITTED mode, no?
>
http://developer.postgresql.org/pgdocs/postgres/transaction-iso.html#XACT-READ-COMMITTED
: it is possible for an updating command to see an inconsistent
: snapshot: it can see the effects of concurrent updating commands
: on the same rows it is trying to update, but it does not see
: effects of those commands on other rows in the database. This
: behavior makes Read Committed mode unsuitable for commands that
: involve complex search conditions
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?
-Kevin