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
Views: Raw Message | Whole Thread | Download 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

Browse pgsql-bugs by date

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