Re: notification: pg_notify ?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mikhail Terekhov <terekhov(at)emc(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>
Subject: Re: notification: pg_notify ?
Date: 2002-04-09 19:42:55
Message-ID: 9345.1018381375@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Mikhail Terekhov <terekhov(at)emc(dot)com> writes:
> Please correct me if I'm wrong but the buffer overrun problem in the new
> LISTEN/NOTOFY mechanism means that it is perfectly possible that sending
> backend may drop all or some of the pending NOTIFY messages in case of such
> an overrun.

You would be guaranteed to get *some* notify. You wouldn't be
guaranteed to receive the auxiliary info that's proposed to be added to
the basic message type; also you might get notify reports for conditions
that hadn't actually been signaled.

> If this is the case then this new mechanism would be step
> backward in terms of functionality relative to the current implementation.

The current mechanism is hardly perfect; it drops multiple occurrences
of the same NOTIFY. Yes, the behavior would be different, but that
doesn't immediately translate to "a step backwards".

> That is exactly what I do in my application. I store messages in a regular
> table and then send a notify to other clients. But I'd like to have a
> guaranty that without system crash all my notifies will be delivered.

Please re-read the proposal. It will not break your application.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-04-09 19:46:33 Re: unknownin/out patch (was [HACKERS] PQescapeBytea is
Previous Message Mattew T. O'Connor 2002-04-09 19:22:32 Re: Strange problem when upgrading to 7.2 with pg_upgrade.