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@xxxxxxxxxx> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
