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