Re: [HACKERS] Proposal for async support in libpq - Mailing list pgsql-hackers

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
SIGURG signal handling, we break the app.  If not, we probably still
break the app, because its signal handling logic is likely expecting
SIGURG only from the other channel.

In short, inbound OOB to the server is OK because we have control of
everything that will be affected.  Outbound OOB is not OK because
we don't.

> One issue raised
> by Stevens' "Unix Network Programming"(p. 333) is that the OOB
> signal(SIGURG) can arrive before the data is ready to be read.

Right.  One advantage of using OOB only for cancel is that the SIGURG
signal itself is the interesting event; you don't really *need* to get
the OOB data to know what to do.  You can read and discard the OOB data
at any convenient point, perhaps just before trying to read normal data
from the client channel.

            regards, tom lane