Re: determine snapshot after obtaining locks for first statement

On Thu, Dec 17, 2009 at 1:12 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
>> I don't think that's any clearer, though it is more disparaging.
>> :-)
>
> It's certainly not my goal to knock PostgreSQL.  The precise
> conditions in which an UPDATE or DELETE can view an inconsistent
> database state (and therefore potentially persist something based on
> that inconsistent state) are that it has a FROM clause and/or
> subqueries which reference data changed by a concurrent database
> transaction which also affects rows which are targets of the UPDATE
> or DELETE.  Precise descriptions of problem circumstances seem more
> useful to developers than vague statements like "it's usually good
> enough, except when it isn't."
>
> If an accurate description of the behavior is considered
> disparaging, perhaps it's the behavior which should change, not just
> the description of it.  Since I never use READ COMMITTED for
> updates, I'm not going to weigh in on whether this is a big enough
> problem to merit the effort and overhead of a different
> implementation; I'm just suggesting we should put the information
> out there more explicitly.  My wording was still a little on the
> vague side, in an attempt to keep it short; perhaps that was a
> mistake.

Don't get me wrong, I don't love the current behavior. (I don't have
a competing proposal either.) But I think we want to describe it with
precision, because there are also many cases where _it works fine_.
Telling people when it works and when it doesn't work is a lot more
useful than attempting to qualitatively estimate how good or bad it
is.

...Robert