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 4B2A2900020000250002D730@gw.wicourts.gov
Whole thread Raw
In response to Re: determine snapshot after obtaining locks for first statement  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: determine snapshot after obtaining locks for first statement
List pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote:
> Tom Lane <tgl@sss.pgh.pa.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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: COPY IN as SELECT target
Next
From: Tom Lane
Date:
Subject: Re: COPY IN as SELECT target