Thread: LISTEN/NOTIFY improvements?

LISTEN/NOTIFY improvements?

From
Aaron Hillegass
Date:
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.

Sincerely,
Aaron Hillegass
Big Nerd Ranch, Inc.
404-210-5663




Re: LISTEN/NOTIFY improvements?

From
Gavin Sherry
Date:
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


Re: LISTEN/NOTIFY improvements?

From
Alvaro Herrera
Date:
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)