Re: Feature request: NOTIFY enhancement

Alvaro Herrera wrote:
> Andreas 'ads' Scherbaum wrote:
>
> > It is possible, that some notifies, if following in a very short time
> > frame, can get lost.
> >
> > In case we want to send extra text messages with NOTIFY, we should make
> > sure, that no notify get lost.
>
> Right.  Currently, NOTIFY acts like Unix signals -- consecutive signals
> can get "collapsed" into a single one, and the listening process is
> responsible for ensuring that it gets the communication details from
> elsewhere.
>
> If the idea is to convert NOTIFY into a full-blown communication system,
> then no collapsing can take place.  This means the additional data
> (which can be of unbounded size) must be stored elsewhere, probably on
> disk.
>
> So far (AFAIK), the only detailed design proposal came from Neil Conway,
> which used SLRU for storage, but AFAIK he didn't take it much further.

TODO has:

    * Allow LISTEN/NOTIFY to store info in memory rather than tables?

      Currently LISTEN/NOTIFY information is stored in pg_listener. Storing
      such information in memory would improve performance.

I have added this to TODO:

    * Allow multiple identical NOTIFY events to always be communicated to the
      client, rather than sent as a single notification to the listener

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +