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
