Re: Processing a work queue
От | Andrew - Supernews |
---|---|
Тема | Re: Processing a work queue |
Дата | |
Msg-id | slrnf3f4hg.2vn3.andrew+nonews@atlantis.supernews.net обсуждение исходный текст |
Ответ на | Processing a work queue (Steve Crawford <scrawford@pinpointresearch.com>) |
Список | 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 по дате отправления: