Re: SELECT FOR UPDATE and LIMIT 1 behave oddly - Mailing list pgsql-bugs

From Tom Lane
Subject Re: SELECT FOR UPDATE and LIMIT 1 behave oddly
Date
Msg-id 5385.1097818216@sss.pgh.pa.us
Whole thread Raw
In response to Re: SELECT FOR UPDATE and LIMIT 1 behave oddly  (Neil Conway <neilc@samurai.com>)
Responses Re: SELECT FOR UPDATE and LIMIT 1 behave oddly  (Neil Conway <neilc@samurai.com>)
List pgsql-bugs
Neil Conway <neilc@samurai.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

pgsql-bugs by date:

Previous
From: Neil Conway
Date:
Subject: Re: SELECT FOR UPDATE and LIMIT 1 behave oddly
Next
From: Neil Conway
Date:
Subject: Re: SELECT FOR UPDATE and LIMIT 1 behave oddly