Re: Listen / Notify rewrite

On Nov 11, 2009, at 4:25 PM, Joachim Wieland wrote:

> Hi,
>
> Attached is a patch for a new listen/notify implementation.
>
> In a few words, the patch reimplements listen/notify as an slru- 
> based queue
> which works similar to the sinval structure. Essentially it is a  
> ring buffer on
> disk with pages mapped into shared memory for read/write access.
>
> Additionally the patch does the following (see below for details):
>
> 1. It removes the pg_listener relation and
> 2. adds the possibility to specify a payload parameter, i.e.  
> executing in SQL
>    "NOTIFY foo 'payload';" and 'payload' will be delivered to any  
> listening
>    backend.
> 3. Every distinct notification is delivered.
> 4. Order is preserved, i.e. if txn 1 first does NOTIFY foo, then  
> NOTIFY bar, a
>    backend (listening to both "foo" and "bar") will always first  
> receive the
>    notification "foo" and then the notification "bar".
> 5. It's now "listen to a channel", not "listen to a relation"  
> anymore...

Hi Joachim,

Thank you for implementing this- LISTEN/NOTIFY without a payload has  
been a major problem to work around for me.

I understand that coalescing multiple notifications of the same name  
happens now, but I never understood why. I had hoped that someone  
revisiting this "feature" would remove it. My use case is autonomous  
transactions.
From a developer's standpoint, NOTIFY specifies a form of remote  
trigger for further action- outside the transaction- to occur. From  
that point of view, I don't see why NOTIFY foo; NOTIFY foo; is  
equivalent to NOTIFY foo;. I understand the use case where a per-row  
trigger could generate lots of spurious notifications, but it seems  
that if anything is generating spurious notifications, the  
notification is in the wrong place.

The documentation makes the strong implication that notification names  
are usually table names, but with the new payload, this becomes even  
less the case.

""I changed this table, take a look at it to see what's new". But no  
such association is enforced by the NOTIFY and LISTEN commands." http://www.postgresql.org/docs/8.4/static/sql-notify.html

With the coalescing, I feel like I am being punished for using NOTIFY  
with something other than a table name use case.

At least with this new payload, I can set the payload to the  
transaction ID and be certain that all the notifications I sent are  
processed (and in order even!) but could you explain why the  
coalescing is still necessary?

While coalescing could be achieved on the receiving-end NOTIFY  
callback ( if(payload ID was already processed) continue; ), non- 
coalescing behavior cannot be achieved when the backend does the  
coalescing.

For backwards compatibility, payload-less NOTIFY could coalesce while  
NOTIFYs with a payload would not coalesce, but, on the other hand,  
that might be confusing.

In any case, thank you for improving this long-neglected subsystem!

Best regards,
M