Re: fixing LISTEN/NOTIFY - Mailing list pgsql-hackers

From Neil Conway
Subject Re: fixing LISTEN/NOTIFY
Date
Msg-id 63069.69.199.116.160.1128880539.squirrel@69.199.116.160
Whole thread Raw
In response to Re: fixing LISTEN/NOTIFY  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: fixing LISTEN/NOTIFY
Re: fixing LISTEN/NOTIFY
List pgsql-hackers
Tom Lane said:
> But I think you might be confusing that with the feature-or-bug
> (depending on one's point of view) that duplicate notifications can be
> merged into one event.  I'm inclined to preserve that behavior,
> primarily because not doing so would create a tremendous penalty on
> applications that expect it to work that way.

What sort of application are you envisioning?

If you mean there are applications for which avoiding duplicate
notifications is a performance win, I think those applications are on
shakey ground: the LISTEN/NOTIFY interface doesn't guarantee that no
duplicate notifications will be delivered (it merely doesn't guarantee
they *will* be delivered).

Personally, I think delivering all notifications by default is simpler
behavior for the application programmer to understand. If you want to
avoid doing work for duplicate notifications, you realistically need to
implement that yourself anyway.

-Neil




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: avoid pulling up subquerys that contain volatile functions?
Next
From: Josh Berkus
Date:
Subject: Re: fixing LISTEN/NOTIFY