| From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
|---|---|
| To: | "James Mancz" <james(at)mancz(dot)com> |
| Cc: | <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Trx issues: SELECT FOR UPDATE LIMIT |
| Date: | 2003-04-30 15:49:02 |
| Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA40184CD94@m0114.s-mxs.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > client 2 can carry on processing now,
> > and its SELECT * FROM work WHERE alloc IS NULL LIMIT 1 FOR UPDATE;
> > **returns no rows** despite the fact the second row matches.
>
> This is annoying but I do not think it is readily fixable, because the
> LIMIT filter acts before the FOR UPDATE processing. When FOR UPDATE
> rejects the first row because it's been changed by the previous updater,
> that's all she wrote --- the LIMIT's not gonna produce more rows.
At least there is a workaround for this:
Use a cursor without (or with a high eg 10000) LIMIT and stop fetching after
the 1000 wanted rows :-)
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Patrick Macdonald | 2003-04-30 17:34:01 | PITR: Proposed modifications to JR's design |
| Previous Message | John Liu | 2003-04-30 15:13:28 | pattern match, index use and performance |