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

From Greg Stark
Subject Re: determine snapshot after obtaining locks for first statement
Date
Msg-id 407d949e0912170949n5f16d13are2f8f8c1eddf4b8b@mail.gmail.com
Whole thread Raw
In response to Re: determine snapshot after obtaining locks for first statement  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: determine snapshot after obtaining locks for first statement
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: COPY IN as SELECT target
Next
From: "Kevin Grittner"
Date:
Subject: Re: determine snapshot after obtaining locks for first statement