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
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. |