| From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
|---|---|
| To: | Csaba Nagy <nagy(at)ecircle-ag(dot)com> |
| Cc: | Postgres general mailing list <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Feature: FOR UPDATE SKIP LOCKED |
| Date: | 2008-07-09 08:52:19 |
| Message-ID: | 48747C43.5080401@postnewspapers.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Csaba Nagy wrote:
> On Wed, 2008-07-09 at 16:23 +0800, Craig Ringer wrote:
>> Especially if it returned an updated row count or supported the
>> RETURNING clause, so you could find out after the fact what was or
>> wasn't done.
>
> Well, it is supposed to be used as "SELECT ... FOR UPDATE SKIP LOCKED",
> so you can in fact put the locked row ids in the target list. With a
> "LIMIT 1" appended would be the perfect way to check out the next queue
> item to process...
That makes sense. I was thinking of UPDATE ... SKIP LOCKED RETURNING
instead, which could be handy in similar situations.
--
Craig Ringer
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Markus | 2008-07-09 08:53:39 | Re: SELECT Query returns empty |
| Previous Message | Csaba Nagy | 2008-07-09 08:45:00 | Re: Feature: FOR UPDATE SKIP LOCKED |