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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026