Re: Listen / Notify - what to do when the queue is full

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