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)
