Re: determine snapshot after obtaining locks for first statement

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

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Are we sure that's a precise and complete description? I don't
>> have a problem with putting a description just like that in the
>> docs, but I'm not yet convinced it's right.
>
> Well, I thought it was when I typed it. You mentioned referencing
> other columns in the updated rows; I'll test to see how that
> behaves.

Some quick testing seems to show that for the rows on which we were
blocking, all columns reflect all updates from the concurrent
transaction on which we were waiting, including columns used in the
WHERE clause. I'm not sure exactly what other tests might be
necessary. I'm having trouble coming up with anything which doesn't
involve a join or subquery, but that could be a failure of
imagination.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-12-17 18:50:55 Re: COPY IN as SELECT target
Previous Message Robert Haas 2009-12-17 18:43:20 Re: COPY IN as SELECT target