From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Listen / Notify - what to do when the queue is full |
Date: | 2009-11-19 01:26:37 |
Message-ID: | 4B049ECD.3020301@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/16/09 3:19 AM, Joachim Wieland wrote:
> 1) drop new notifications if the queue is full (silently or with rollback)
> 2) block until readers catch up (what if the backend that tries to write the
> notifications actually is the "lazy" reader that everybody is waiting for to
> proceed?)
> 3) invent a new signal reason and send SIGUSR1 to the "lazy" readers, they
> need to interrupt whatever they are doing and copy the
> notifications into their
> own address space (without delivering the notifications since they are in a
> transaction at that moment).
(4) drop *old* notifications if the queue is full.
Since everyone has made the point that LISTEN is not meant to be a full
queueing system, I have no problem dropping notifications LRU-style. If
we've run out of room, the oldest notifications should go first; we
probably don't care about them anyway.
We should probably also log the fact that we ran out of room, so that
the DBA knows that they ahve a design issue. For volume reasons, I
don't think we want to log every dropped message.
Alternately, it would be great to have a configuration option which
would allow the DBA to choose any of 3 behaviors via GUC:
drop-oldest (as above)
drop-largest (if we run out of room, drop the largest payloads first to
save space)
error (if we run out of room, error and rollback)
--Josh Berkus
From | Date | Subject | |
---|---|---|---|
Next Message | KaiGai Kohei | 2009-11-19 01:54:02 | Re: [HACKERS] TRIGGER with WHEN clause |
Previous Message | Andrew Chernow | 2009-11-19 01:26:18 | Re: Listen / Notify - what to do when the queue is full |