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