Re: notification: pg_notify ?
От | Neil Conway |
---|---|
Тема | Re: notification: pg_notify ? |
Дата | |
Msg-id | 1016770832.7733.64.camel@jiro обсуждение исходный текст |
Ответ на | Re: notification: pg_notify ? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: notification: pg_notify ?
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: notification: pg_notify ? ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>) |
Список | pgsql-hackers |
On Thu, 2002-03-21 at 22:41, Tom Lane wrote: > Neil Conway <nconway@klamath.dyndns.org> writes: > > Solution: Create a new system catalog, pg_notify. > > It's not apparent to me why that helps much. Well, it solves the functional problem at hand -- this feature can now be implemented. However, I agree with you that there are still problems with NOTIFY and pg_listener, as you have outlined. > So if someone wants to undertake a revision of the listen/notify code, > I think the first thing to do ought to be to throw away pg_listener > entirely and develop some lower-overhead, shared-memory-based > communication mechanism. You could do worse than to use the shared > cache inval code as a model --- or perhaps even incorporate LISTEN > signaling into that mechanism. (Actually that seems like a good plan, > so as not to use shared memory inefficiently by dedicating two separate > memory pools to parallel purposes.) That's very interesting. I need to read the code you're referring to before I can comment further, but I'll definately look into this. That's a good idea. > If you follow the SI model then NOTIFY messages would essentially be > broadcast to all backends, My apologies, but what's the SI model? > A deficiency of the SI implementation (and probably anything else that > relies solely on shared memory) is that it can suffer from buffer > overrun, since there's a fixed-size message pool. For the purposes > of cache inval, we cope with buffer overrun by just invalidating > everything in sight. It might be a workable tradeoff to cope with > buffer overrun for LISTEN/NOTIFY by reporting notifies on all conditions > currently listened for. This assumes that the NOTIFY condition we're waiting for is fairly routine (e.g. "table x is updated, refresh the cache"). If a NOTIFY actually represents the occurence of a non-trivial condition, this could be a problem (e.g. "the site crashed, page the sys-admin", and the buffer happens to overflow at 2 AM :-) ). However, it's questionable whether that is an appropriate usage of NOTIFY. > BTW, I would like to see a spec for this "notify with parameter" feature > before it's implemented, not after. What information would you like to know? > Exactly what semantics do you have in mind? The current syntax I'm using is: NOTIFY condition_name [ [WITH MESSAGE] 'my message' ]; But I'm open to suggestions for improvement. Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
В списке pgsql-hackers по дате отправления:
Следующее
От: "Nicolas Bazin"Дата:
Сообщение: Re: Where to get official SQL spec (was Re: Domain Support)