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 [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
