Re: notification: pg_notify ? - Mailing list 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