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