Skip site navigation (1) Skip section navigation (2)

Re: SELECT FOR UPDATE and LIMIT 1 behave oddly

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: SELECT FOR UPDATE and LIMIT 1 behave oddly
Date: 2004-10-15 05:30:16
Message-ID: 5385.1097818216@sss.pgh.pa.us (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-bugs
Neil Conway <neilc(at)samurai(dot)com> writes:
> On Fri, 2004-10-15 at 14:22, Tom Lane wrote:
>> What if some of the locked rows didn't get returned to the client?

> In the case of SELECT ... FOR UPDATE LIMIT x, exactly the same condition
> applies: some number of locked rows will not be returned to the client.

Au contraire: every row that gets locked will be returned to the client.
The gripe at hand is that the number of such rows may be smaller than
the client wished, because the LIMIT step is applied before we do the
FOR UPDATE step (which has not only the effect of locking selected rows,
but of disregarding rows that were deleted since our query snapshot).

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: Neil ConwayDate: 2004-10-15 05:37:10
Subject: Re: SELECT FOR UPDATE and LIMIT 1 behave oddly
Previous:From: Neil ConwayDate: 2004-10-15 05:21:02
Subject: Re: SELECT FOR UPDATE and LIMIT 1 behave oddly

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group