Jeff Davis wrote: > On Tuesday 02 July 2002 06:03 pm, Bruce Momjian wrote: > > Let me tell you what would be really interesting. If we didn't report > > the pid of the notifying process and we didn't allow arbitrary strings > > for notify (just pg_class relation names), we could just add a counter > > to pg_class that is updated for every notify. If a backend is > > listening, it remembers the counter at listen time, and on every commit > > checks the pg_class counter to see if it has incremented. That way, > > there is no queue, no shared memory, and there is no scanning. You just > > pull up the cache entry for pg_class and look at the counter. > > > > One problem is that pg_class would be updated more frequently. Anyway, > > just an idea. > > I think that currently a lot of people use select() (after all, it's mentioned > in the docs) in the frontend to determine when a notify comes into a > listening backend. If the backend only checks on commit, and the backend is > largely idle except for notify processing, might it be a while before the > frontend realizes that a notify was sent?
I meant to check exactly when it does now; when a query completes. -- 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 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
