Re: listen/notify argument (old topic revisited)

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.
> 
> 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.

I don't see a huge value to using shared memory.   Once we get
auto-vacuum, pg_listener will be fine, and shared memory like SI is just
too hard to get working reliabily because of all the backends
reading/writing in there.  We have tables that have the proper sharing
semantics;  I think we should use those and hope we get autovacuum soon.

As far as the message, perhaps passing the oid of the pg_listener row to
the backend would help, and then the backend can look up any message for
that oid in pg_listener.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026