Re: determine snapshot after obtaining locks for first statement

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "Markus Wanner" <markus(at)bluegap(dot)ch>, <pgsql-hackers(at)postgresql(dot)org>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: determine snapshot after obtaining locks for first statement
Date: 2009-12-17 19:05:15
Message-ID: 4B2A2C8B020000250002D738@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-12-17 19:17:52 Re: COPY IN as SELECT target
Previous Message Tom Lane 2009-12-17 19:00:28 Re: determine snapshot after obtaining locks for first statement