Re: determine snapshot after obtaining locks for first statement

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: determine snapshot after obtaining locks for first statement
Дата
Msg-id 4120.1261071598@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: determine snapshot after obtaining locks for first statement  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: COPY IN as SELECT target
Следующее
От: Robert Haas
Дата:
Сообщение: Re: COPY IN as SELECT target