On Tue, 9 Apr 2002, Tom Lane wrote:
> Mikhail Terekhov <terekhov@emc.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