Re: Processing a work queue - Mailing list pgsql-general

From Andrew - Supernews
Subject Re: Processing a work queue
Date
Msg-id slrnf3f4hg.2vn3.andrew+nonews@atlantis.supernews.net
Whole thread Raw
In response to Processing a work queue  (Steve Crawford <scrawford@pinpointresearch.com>)
List pgsql-general
On 2007-04-30, "John D. Burger" <john@mitre.org> wrote:
> Andrew - Supernews wrote:
>
>>> Anyone have any ideas on how to handle a work queue?
>>
>> Advisory locks (userlocks in pre-8.2).
>
> Can someone explain why these are a better fit than whatever locks
> SELECT FOR UPDATE acquires?

They can be acquired without blocking, and they are non-transactional (and
can therefore be held for long periods of time, while you work on the item -
this allows you to either detect cases where a queue runner died before
completing an item, or (where appropriate) automatically release such items
back into the queue).

The nonblocking bit avoids the need for a backoff-and-retry in the case
when two queue runners both try and fetch from the queue at the same time -
using advisory locks they both get a (different) item, rather than one
getting a serialization failure.

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

pgsql-general by date:

Previous
From: Robert Treat
Date:
Subject: Re: Questions about TSearch2 and PG 8.2
Next
From: "Alexander Staubo"
Date:
Subject: Re: PostgreSql replication and load balancing ( is Slony-I a solution?)