LISTEN/NOTIFY improvements?

On Thu, 16 Dec 2004, Aaron Hillegass wrote:

I am a programmer who works on a couple of products that use PostgreSQL
as their backend (http://www.nopali.com, http://www.iwanttops.com).
Both my clients need to receive notifications when rows in the database
change. Thus far, we've been rolling our own because LISTEN/NOTIFY
doesn't do what we need.

What we need is on the TODO list:
- Add optional textual message to NOTIFY: This would allow an
informational message to be added to the notify message, perhaps
indicating the row modified or other custom information.

I want to help get this done for 8.1, but lack the deep understanding
necessary. Is there someone on this list that I can beg/bribe to make
this happen? I would be delighted to do stress-testing and
benchmarking on the resulting code.

(Incidentally, there are two related TODO items you might want to take
care of while you are in there:
- Allow NOTIFY in rules involving conditionals
- 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.)

Regardless, thank you for all the great work that you have been doing;
PostgreSQL has made my life a better place.

I've got a patch floating around that does this and also moves
LISTEN/NOTIFY into the shared inval code -- which means its faster but
still suffers the problem of relying on a statically sized shared memory
buffer. The point is, I can get the patch into shape without too much
trouble and send it in for 8.1. The great thing is that the patch does not
break the FE/BE protocol because Tom had the foresight to allow optional
messages with NOTIFY events. You legend.

Thanks,

Gavin

On Fri, Dec 17, 2004 at 09:56:05AM +1100, Gavin Sherry wrote:

I've got a patch floating around that does this and also moves
LISTEN/NOTIFY into the shared inval code

Uh, what will happen with idle backends?

--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
Maybe there's lots of data loss but the records of data loss are also lost.
(Lincoln Yeoh)