From: Bruce Momjian <bruce@momjian.us>
Message-Id: <201006161416.o5GEGPD14227@momjian.us>
Subject: Re: For update clause
In-Reply-To: <201006160958.16216.cousinflo@free.fr>
To: Florence Cousin <cousinflo@free.fr>
Date: Wed, 16 Jun 2010 10:16:25 -0400 (EDT)
CC: pgsql-docs@postgresql.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"

Florence Cousin wrote:
> Le mardi 15 juin 2010 22:04:06, Bruce Momjian a ?crit :
> > 
> > Wow, that is a confusing double-negative sentence.  I have updated the
> > text to be:
> > 
> >     In addition, rows that satisfied the query conditions as of the
> >     query snapshot will be locked, although they will not be returned
> >     if they were updated after the snapshot and no longer satisfy the
> >     query conditions.
> > 
> > What it is saying is that SELECT FOR UPDATE will lock all rows that
> > match the SELECT query using the current snapshot, but the returned rows
> > might be different because the rows were changed after the snapshot was
> > taken, and a SELECT FOR UPDATE will return the rows as UPDATE will see
> > them, which might not match the SELECT snapshot.  Yeah, it is confusing.
> 
> Thank you for the patch and the explanation. It is clear for me now (the rows 
> returned are those that would be returned by an UPDATE, that is pretty 
> logical).
> 
> But I think most of the users will still not understand this, because they do 
> not know what a snapshot is, and do not really know how locking works. 
> 
> And I managed to understand thank to the explanation, but I think I could not 
> understand with the new version of the explanation alone (the fact that rows 
> returned are the rows as UPDATE will see them)
> 
> Maybe it would be clearer with a longer explanation, or a link to an 
> explanation?

Well, the entire area is very complicated, but do we want to add even
more text there?  I am not sure.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + None of us is going to be here forever. +