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
