| 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 | Resend email |
| 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
| 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 |