Tom Lane wrote:
>
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> >> I don't see any real need to issue outgoing notifications as OOB data.
>
> > Well, if you are trying to prevent from sending queries through libpq to
> > see if you have any notifications, how will you get notification without
> > an OOB-generated signal? The notification would have to come through a
> > packet from the backend, and I thought you didn't want to have to deal
> > with that?
>
> No, I have no problem with getting a regular packet from the backend
> when the notify condition occurs. What I don't like is creating excess
> network traffic above and beyond the notification packet --- especially
> not having to "poll" continuously to see whether the condition has
> occurred. But using select() to wait for something to happen does not
> induce network traffic.
>
> The only advantage of sending outgoing notifications as OOB is the fact
> that a SIGURG signal gets delivered to the recipient, which could be
> used to trigger abandonment of some current operation. But I have a
> hard time perceiving where a client would want that, as opposed to
> detecting the notify after it completes whatever it's currently doing.
>
> Sending cancellation requests inbound to the server is exactly what OOB
> is for, because there you must interrupt current processing to get the
> desired result. Outbound notify signals are a different thing IMHO.
> An SQL NOTIFY is typically going to trigger new processing in the
> client, not cancel an operation in progress.
>
> There are positive reasons *not* to force applications to handle
> notifies as OOB data, primarily having to do with portability and risk
> of breaking things. For example, consider a frontend app that already
> deals with OOB/SIGURG on a different input channel. If libpq takes over
When the Postgresql library installs its signal handler for SIGURG, it
can find out if one was already in place. If so, it can check to see
if the SIGURG is for that other handler and the postgres handler can
call the other handler.
Ocie
