Mikhail Terekhov <[EMAIL PROTECTED]> 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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to