Обсуждение: Is LISTEN/NOTIFY reliable?
Hi, 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? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp
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
<br /><br /> On 10/16/2010 09:04 AM, Robert Haas wrote: <blockquote cite="mid:AANLkTinmP0sMVd2ErLdDba=1VftnvOcHYBE52tjxzdsB@mail.gmail.com"type="cite"><pre wrap="">On Sat, Oct 16, 2010 at 3:27AM, Tatsuo Ishii <a class="moz-txt-link-rfc2396E" href="mailto:ishii@postgresql.org"><ishii@postgresql.org></a>wrote: </pre><blockquote type="cite"><pre wrap="">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? </pre></blockquote><pre wrap=""> 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... </pre></blockquote><br /> Here's what the docs say:<br /><br /><blockquote>If the same channel name is signaled multipletimes from the same transaction with identical payload strings, the database server can decide to deliver a singlenotification only. On the other hand, notifications with distinct payload strings will always be delivered as distinctnotifications. Similarly, notifications from different transactions will never get folded into one notification.Except for dropping later instances of duplicate notifications, <tt class="COMMAND">NOTIFY</tt> guarantees thatnotifications from the same transaction get delivered in the order they were sent.<br /></blockquote><br /> cheers<br/><br /> andrew<br />
> 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? ,A (BI 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... Thanks. Maybe I was confused by the bug. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp