Re: notification: pg_notify ?

Tom Lane wrote:

> LISTEN/NOTIFY is basically designed for invalidate-your-cache
> arrangements (which is what led into this discussion originally, no?).

Why do you think so? Even if you are right and original design was
just for invalidate-your-cache arrangements, current implementation
has much more functionality and can be used as a reliable message
transmission mechanism (we use it that way). There is no reason to
broke this reliability.

> 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.
>

There are not only caching arrangements out there!
This resembles me the difference between poll(2) and select(2).
They are both useful in different cases.

> I can certainly imagine applications where the messages are too
> important to trust to a not-fully-reliable transmission medium;

That is exactly what we are using LISTEN/NOTIFY for. We don't need
separate message passing system, we don't need waste system resources
polling database and application is simpler and easier to maintain.

> but I don't think that LISTEN/NOTIFY should be loaded down with
> that sort of requirement. You can easily build 100% reliable

This functionality is already in Postgres.

May be it is not perfect but why remove it?

> (and correspondingly slow and expensive) communications mechanisms
> using standard SQL operations. I think the design center for

Could you please elaborate on how to do that without polling?

> 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.
>
Again, client side cache is not the only one application of LISTEN/NOTIFY.

If we need a cheap mechanism for maintaining client side cache let's
implement one. Why remove existing functionality!