From: | Andrew - Supernews <andrew+nonews(at)supernews(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Processing a work queue |
Date: | 2007-05-01 19:17:04 |
Message-ID: | slrnf3f4hg.2vn3.andrew+nonews@atlantis.supernews.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2007-04-30, "John D. Burger" <john(at)mitre(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Staubo | 2007-05-01 20:17:35 | Re: PostgreSql replication and load balancing ( is Slony-I a solution?) |
Previous Message | Robert Treat | 2007-05-01 19:12:19 | Re: Questions about TSearch2 and PG 8.2 |