Re: notification: pg_notify ?

Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> writes:
>> Because there is no other easy way to guarantee message delivery?

> Shared memory is much easier and, to all intents and purposes, as reliable
> for this kind of usage. It is much faster and is the-right-way-to-do-it.

Right. Since we do not attempt to preserve NOTIFY messages over a
system crash, there's no good reason to keep the messages in a table.
Except for the problem that shared memory is of limited size.
But if we are willing to define the semantics in a way that allows
buffer overflow recovery, that can be dealt with.

> A buffer overrun (rare as it would be,
> considering the different usage patterns of the shared memory for
> notification) would result in an elog(ERROR) from within the backend which
> has attempted to execute the notification.

Hmm. That's a different way of attacking the overflow problem. I don't
much care for it, but I can see that some applications might prefer this
behavior to cache-style overrun response (ie, issue forced NOTIFYs on
all conditions). Maybe support both ways?

regards, tom lane