Re: Lock/deadlock issues with priority queue in Postgres - possible VACUUM conflicts

Поиск
Список
Период
Сортировка
От Chris Angelico
Тема Re: Lock/deadlock issues with priority queue in Postgres - possible VACUUM conflicts
Дата
Msg-id CAPTjJmoXQEJMgyc+tWMc05uOyk01bQ8PgCVsLstLwEVtV5kigQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Lock/deadlock issues with priority queue in Postgres - possible VACUUM conflicts  (Marko Kreen <markokr@gmail.com>)
Ответы Re: Lock/deadlock issues with priority queue in Postgres - possible VACUUM conflicts  (Marko Kreen <markokr@gmail.com>)
Список pgsql-general
On Tue, Jan 31, 2012 at 4:12 AM, Marko Kreen <markokr@gmail.com> wrote:
> On Mon, Jan 9, 2012 at 5:58 AM, Chris Angelico <rosuav@gmail.com> wrote:
>> http://wiki.postgresql.org/wiki/PGQ_Tutorial
>>
>> PGQ looks promising, but I can't afford the risk of losing calls in
>> the event that there are no workers to process them (the correct
>> action is for them simply to languish in the database until one is
>> started up).
> PGQ does not lose events - after consumer registers
> on the queue it is guaranteed to see all events.
>
> So it's a matter of registering your consumers
> before anything interesting happens in database.
> The actual consumers do not need to be running
> at that moment.

Ah, I think I understand. So registering a consumer simply means
registering its textual name. I was under the impression that it
registered the session/connection it was on. PGQ may still be
unsuitable (it's more geared toward replication than a shared-workload
scenario), but that's my primary concern solved.

ChrisA

В списке pgsql-general по дате отправления:

Предыдущее
От: John R Pierce
Дата:
Сообщение: Re: Postgresql logging questions
Следующее
От: Marko Kreen
Дата:
Сообщение: Re: Lock/deadlock issues with priority queue in Postgres - possible VACUUM conflicts