Re: notification: pg_notify ? - Mailing list pgsql-hackers

What if we used a combination of the two approaches?  That is, when an
overflow occurs, overflow into a table?  That way, nothing is lost and
spurious random events don't have to occur.  That way, things are faster
when overflows are not occurring.  When the system gets too far behind,
it simply overflows into the the existing table until the system can
catch up.  This way, we don't have to waste resources notifying listens
that would otherwise not need to be notified.

Greg




On Fri, 2002-03-22 at 23:13, Tom Lane wrote:
> Neil Conway <nconway@klamath.dyndns.org> writes:
> > (1) Use the shared-memory-based buffer scheme you suggested. When a
> > backend executes a NOTIFY, it stores it until transaction commit (as in
> > current sources). When the transaction commits, it checks to see if
> > there would be a buffer overflow if it added the NOTIFY to the buffer --
> > if so, it complains loudly to the log, and sleeps. When it awakens, it
> > repeats (try to add to buffer; else, sleep).
>
> This is NOT an improvement over the current arrangement.  It implies
> that a notification might be postponed indefinitely, thereby allowing
> listeners to keep using stale data indefinitely.
>
> LISTEN/NOTIFY is basically designed for invalidate-your-cache
> arrangements (which is what led into this discussion originally, no?).
> In *any* caching arrangement, it is far better to have the occasional
> spurious data drop than to fail to drop stale data when you need to.
> Accordingly, a forced cache clear is an appropriate response to
> overrun of the communications buffer.
>
> I can certainly imagine applications where the messages are too
> important to trust to a not-fully-reliable transmission medium;
> but I don't think that LISTEN/NOTIFY should be loaded down with
> that sort of requirement.  You can easily build 100% reliable
> (and correspondingly slow and expensive) communications mechanisms
> using standard SQL operations.  I think the design center for
> LISTEN/NOTIFY should be exactly the case of maintaining client-side
> caches --- at least that's what I used it for when I had occasion
> to use it, several years ago when I first got involved with Postgres.
> And for that application, a cheap mechanism that never loses a
> notification, but might occasionally over-notify, is just what you
> want.
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org