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 4B2A2C8B020000250002D738@gw.wicourts.gov
Whole thread Raw
In response to Re: determine snapshot after obtaining locks for first statement  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> wrote:
> 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.
It sounds like we're in violent agreement.  I'm not sure what I said
which might have led you to believe I felt otherwise.
[reviews thread]
The suggestion you felt was "more disparaging" was:
: This behavior makes Read Committed mode unsuitable for
: many UPDATE or DELETE commands with joins or subqueries
You do realize that what is already in the documentation, for which
this was a suggested replacement, was?:
: This behavior makes Read Committed mode unsuitable for
: commands that involve complex search conditions
I'm not seeing where I made it more disparaging; I was trying to
clarify under what circumstances it was a problem.  If you have a
suggestion for a better way to phrase the part I left alone, feel
free to suggest something.
-Kevin


pgsql-hackers by date:

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