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
