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

A combined reply to several comments:

Phil Thompson <phil@river-bank.demon.co.uk> writes:
> While I understand the desire to implement async support with the
> minimum of fuss, SQL3 provides the ASYNC, TEST and WAIT statements.
> This would be a more "standard" solution,

... but it doesn't solve the problem.  My concern is first to get rid
of the need to issue dummy queries to detect NOTIFY responses.  This is
clearly not an SQL language issue, only a matter of poor design of libpq.
The business about supporting async queries is just a nice bonus as far
as I'm concerned.

I don't believe I would want to use the SQL3 approach even if we had it.
I don't know SQL3, but if I make the obvious guess about how these are
supposed to work, then you need a round trip to the server to issue an
async query, and another round trip every time you want to see if it's
done.  (Plus one to fetch the results?)  Now as far as I'm concerned,
the point of these changes is to *decrease* communication loads and
unproductive server cycles.  Not increase them.  I want a scheme that
doesn't require the client to create busywork for itself, the server,
and the network.


Peter T Mount <psqlhack@maidast.demon.co.uk> writes:
> Just a quick question: If you have an OOB packet sent to the backend, how
> would we handle the case where a row is being sent to the backend, but the
> OOB packet comes in the middle of it?

This is the same copy in/out issue I asked about yesterday, no?
I think what Bruce had in mind was that the backend would check for
an OOB cancel once per row, or something like that.  This needs to
be documented, but it seems reasonable...


Bruce Momjian <maillist@candle.pha.pa.us> writes:
> In backend/libpq/pqcomm.c, I see pg_sendoob() which sends out-of-band
> data FROM the backend TO the client, but it is not called from anywhere.
> This could be a method of signaling that a notification was pending, and
> sending out-of-band data FROm the client TO the backend could be used
> for cancelling a query.

I don't see any real need to issue outgoing notifications as OOB data.
If the client needed to interrupt current processing to handle a notify,
then maybe it'd be useful, but how likely is that?  Keep in mind that
the backend currently delays notify reports until end of transaction.
I don't think we really want to change that...

This brings up another issue that I meant to ask about before: exactly
what is the relation between interfaces/libpq and backend/libpq?  It
sorta looks like they were once the same code.  Why were they allowed to
become different, and is there any point in trying to unify them again?


Maarten Boekhold wrote:
> Wasn't the problem with OOB data that java doesn't support this?

I was a little concerned about that too, but as long as we only use it
for noncritical functionality like query cancellation, I don't see that
it's a killer if some environments don't have it.  But if the server
issued outgoing notifies via OOB, then we'd have a serious loss of
functionality in any environment without OOB.

            regards, tom lane