Re: listen/notify argument (old topic revisited)

On Tue, Jul 02, 2002 at 02:37:19AM -0700, Jeff Davis wrote:
> A while ago, I started a small discussion about passing arguments to a NOTIFY
> so that the listening backend could get more information about the event.

Funny, I was just about to post to -hackers about this.

> There wasn't exactly a consensus from what I understand, but the last thing I
> remember is that someone intended to speed up the notification process by
> storing the events in shared memory segments (IIRC this was Tom's idea). That
> would create a remote possibility of a spurious notification, but the idea is
> that the listening application can check the status and determine what
> happened.

Yes, that was Tom Lane. IMHO, we need to replace the existing
pg_listener scheme with an improved model if we want to make any
significant improvements to asynchronous notifications. In summary,
the two designs that have been suggested are:

pg_notify: a new system catalog, stores notifications only --
pg_listener stores only listening backends.

shmem: all notifications are done via shared memory and not stored
in system catalogs at all, in a manner similar to the cache
invalidation code that already exists. This avoids the MVCC-induced
performence problem with storing notification in system catalogs,
but can lead to spurrious notifications -- the statically sized
buffer in which notifications are stored can overflow. Applications
will be able to differentiate between overflow-induced and regular
messages.

> Is someone still interested in implementing this feature? Are there still
> people who disagree with the above implementation strategy?

Some people objected to shmem at the time; personally, I'm not really
sure which design is best. Any comments from -hackers?

If there's a consensus on which route to take, I'll probably implement
the preferred design for 7.3. However, I think that a proper
implementation of notify messages will need an FE/BE protocol change,
so that will need to wait for 7.4.

Cheers,

Neil

--
Neil Conway <neilconway(at)rogers(dot)com>
PGP Key ID: DB3C29FC