Re: Processing a work queue

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

In response to

Browse pgsql-general by date

  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