Re: notification: pg_notify ?
От | Gavin Sherry |
---|---|
Тема | Re: notification: pg_notify ? |
Дата | |
Msg-id | Pine.LNX.4.21.0204101054510.28981-100000@linuxworld.com.au обсуждение исходный текст |
Ответ на | Re: notification: pg_notify ? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: