Is LISTEN/NOTIFY reliable?

On Sat, Oct 16, 2010 at 3:27 AM, Tatsuo Ishii <ishii@postgresql.org> wrote:

Does anybody know PostgreSQL LISTEN/NOTIFY is more reliable than
previous versions?  I vaguely recall that in the previous
implementation, message sent by NOTIFY may not be reached to listner.
Does PostgreSQL 9.0's new implementation guarantee that the message is
received by the listener?

I think it was always intended to be reliable (otherwise it's not much
good). I think I remember a bug where notifications were being lost
on Windows under heavy load, but I thought we fixed that...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Tatsuo Ishii <ishii@postgresql.org> writes:

Does anybody know PostgreSQL LISTEN/NOTIFY is more reliable than
previous versions? I vaguely recall that in the previous
implementation, message sent by NOTIFY may not be reached to listner.
Does PostgreSQL 9.0's new implementation guarantee that the message is
received by the listener?

No more or less than the old one did.

The old design intentionally dropped duplicate notifications, and the
new one does too (though with a narrower definition of "duplicate").
Modulo that well-documented behavior, I know of no reason to describe
either the old or new code as unreliable.

regards, tom lane

On 10/16/2010 09:04 AM, Robert Haas wrote:

On Sat, Oct 16, 2010 at 3:27 AM, Tatsuo Ishii<ishii@postgresql.org> wrote:

Does anybody know PostgreSQL LISTEN/NOTIFY is more reliable than
previous versions? I vaguely recall that in the previous
implementation, message sent by NOTIFY may not be reached to listner.
Does PostgreSQL 9.0's new implementation guarantee that the message is
received by the listener?

I think it was always intended to be reliable (otherwise it's not much
good). I think I remember a bug where notifications were being lost
on Windows under heavy load, but I thought we fixed that...

Here's what the docs say:

If the same channel name is signaled multiple times from the same
transaction with identical payload strings, the database server can
decide to deliver a single notification only. On the other hand,
notifications with distinct payload strings will always be delivered
as distinct notifications. Similarly, notifications from different
transactions will never get folded into one notification. Except for
dropping later instances of duplicate notifications, NOTIFY
guarantees that notifications from the same transaction get
delivered in the order they were sent.

cheers

andrew

[Message body could not be decoded - encoding: 7bit, error: code converter not found (ISO-2022-JP-2 to UTF-8)]