Re: BUG #6088: copy to stdout cannot be stopped with kill(pid) or pg_terminate_backend

Maxim Boguk <maxim.boguk@gmail.com> writes:
> However, and here is unusual part: first 135GB of the table is
> completely dead/empty space without single live tuple

Ouch.

> So, (and here going pure theory), while code perform seq scan over
> large empty space it is not perform check for interrupts while looping
> over completely dead/empty area.

Yeah, I think that might well be the case.  We could possibly throw a
CHECK_FOR_INTERRUPTS into heapgetpage or someplace nearby; but on the
other hand, a situation like that is going to be catastrophic for
performance in so many ways that I'm not sure worrying about interrupt
response latency is worthwhile.

            regards, tom lane