On Tue, 9 Apr 2002, Tom Lane wrote: > Mikhail Terekhov <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
