Re: BUG #6088: copy to stdout cannot be stopped with kill(pid) or pg_terminate_backend - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #6088: copy to stdout cannot be stopped with kill(pid) or pg_terminate_backend
Date
Msg-id 25564.1309659203@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #6088: copy to stdout cannot be stopped with kill(pid) or pg_terminate_backend  (Maxim Boguk <maxim.boguk@gmail.com>)
List pgsql-bugs
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

pgsql-bugs by date:

Previous
From: Maxim Boguk
Date:
Subject: Re: BUG #6088: copy to stdout cannot be stopped with kill(pid) or pg_terminate_backend
Next
From: Jon Nelson
Date:
Subject: Re: view + explain + index scan -> bogus varno: 65001 (with some variations)