Re: determine snapshot after obtaining locks for first statement

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: determine snapshot after obtaining locks for first statement
Дата
Msg-id 407d949e0912170949n5f16d13are2f8f8c1eddf4b8b@mail.gmail.com
обсуждение исходный текст
Ответ на Re: determine snapshot after obtaining locks for first statement  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: determine snapshot after obtaining locks for first statement  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Dec 17, 2009 at 5:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

I wonder if RETURNING hasn't created a whole new set of cases where
our READ COMMITTED behaviour is bogus. I guess it's equivalent to
having used SELECT FOR UPDATE.

--
greg


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: COPY IN as SELECT target
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: determine snapshot after obtaining locks for first statement