""Charles Duffy"" <[EMAIL PROTECTED]> wrote > > We came up with this patch in response to a problem reported to us by a > client. They had a query which took an unacceptably long time to respond > to a cancel request (SIGINT). The client uses 8.1.4, so the patch is > against that. > How long is that "unacceptably long time"?
> Their work_mem setting was rather large (1000000). We determined that when it > received SIGINT, the backend was always inside qsort(), so it wouldn't > call ProcessInterrupts() again until it finished this large in-memory > sort. Upon entering tuplesort_performsort(), state->memtupcount was > 29247. > I agree that we may need to consider to let qsort() check interrupts, but the problem here is that 29247 doesn't look like a big number so I can't see why your patch solved the problem, unless the qsort_comparetup() function of the data type eats too many circles or the cpu is too slow. I just did a test to invoke a qsort on an "integer" field of a table with 5 million rows, and sent a SIGINT, the delay is 7 or 8 seconds. I suspect there are some other places doesn't check interrupts -- what's your query plan? Regards, Qingqing ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq