Re: [HACKERS] Proposal for async support in libpq

b>
> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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)