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
|
Список | 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 по дате отправления: