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

From Kevin Grittner
Subject Re: determine snapshot after obtaining locks for first statement
Date
Msg-id 4B2A2012020000250002D711@gw.wicourts.gov
Whole thread Raw
In response to Re: determine snapshot after obtaining locks for first statement  (Robert Haas <robertmhaas@gmail.com>)
Responses 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  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.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.
-Kevin


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: determine snapshot after obtaining locks for first statement
Next
From: Tom Lane
Date:
Subject: Re: determine snapshot after obtaining locks for first statement