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