Re: notification: pg_notify ?

On Tue, 9 Apr 2002, Tom Lane wrote:

> Mikhail Terekhov <terekhov(at)emc(dot)com> writes:
> > Please correct me if I'm wrong but the buffer overrun problem in the new
> > LISTEN/NOTOFY mechanism means that it is perfectly possible that sending
> > backend may drop all or some of the pending NOTIFY messages in case of such
> > an overrun.
>
> You would be guaranteed to get *some* notify. You wouldn't be
> guaranteed to receive the auxiliary info that's proposed to be added to
> the basic message type; also you might get notify reports for conditions
> that hadn't actually been signaled.

I poked around the notify code and had a think about the ideas which have
been put forward. I think the buffer overrun issue can be addressed by
allowing users to define the importance of the notify they are making. Eg:

NOTIFY HARSH <condition>

If there is to be a buffer overrun, all conditions are notified and the
buffer is, eventually, reset.

NOTIFY SAFE <condition>

(Yes, bad keywords). This on the other hand would check if there is to be
a buffer overrun and (after a SendPostmasterSignal(PMSIGNAL_WAKEN_CHILDREN)
fails to reduce the buffer) it would invalidate the transaction with an
elog(ERROR). This can be done since AtCommit_Notify() is run before
RecordTransactionCommit().

This does not deal with recovery from a crash. The only way it could is by
plugging the listen and notify signals into the xlog. This seems very
messy though.

Gavin