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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
