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)
Список
Дерево обсуждения
Re: notification: pg_notify ? Mikhail Terekhov <terekhov@emc.com>
Re: notification: pg_notify ? Tom Lane <tgl@sss.pgh.pa.us>
Re: notification: pg_notify ? Gavin Sherry <swm@linuxworld.com.au>
On Tue, 9 Apr 2002, Tom Lane wrote: > Mikhail Terekhov 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 If there is to be a buffer overrun, all conditions are notified and the buffer is, eventually, reset. NOTIFY SAFE (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 по дате отправления