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 <[EMAIL PROTECTED]>
PGP Key ID: DB3C29FC
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
