Re: listen/notify argument (old topic revisited)

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