Re: [HACKERS] Proposal for async support in libpq

b>
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > You supply the indication to the backend, and I will see that the
> > backend processes it properly.
>
> You're on ;-)
>
> Signaling the cancel request via OOB sounds reasonable, as long as
> nothing else is using it and all the systems we care about support it.
> (I see a couple of routines to support OOB data in
> src/backend/libpq/pqcomm.c, but they don't seem to be called from
> anywhere.  Vestiges of an old protocol, perhaps?)

Probably.  There is a document on the libpq protocol somewhere.  I
assume you have that already.  It is pgsql/docs/programmer.ps.gz, around
page 118.

>
> I still need to understand better what the backend will send back
> in response to a cancel request, especially if it's idle by the
> time the request arrives.  Will that result in an asynchronous error
> response of some sort?  Do I need to make said response visible to
> the frontend application?  (Probably not ... it will have already
> discovered that the query completed normally.)

Not sure the backend has to signal that it received the cancel request.
Does it?  It could just return a NULL result, that I think is caused by
elog(ERROR) anyway, and we can put in some nice fancy text like 'query
aborted'.


>
> How should cancellation interact with copy in/out?

Not sure on that one.  May not be possible or desirable, but we could
put something in commands/copy.c to check for cancel request.



--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)