| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com> |
| Cc: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #6088: copy to stdout cannot be stopped with kill(pid) or pg_terminate_backend |
| Date: | 2011-07-03 02:13:23 |
| Message-ID: | 25564.1309659203@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Maxim Boguk <maxim(dot)boguk(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jon Nelson | 2011-07-03 03:16:16 | Re: view + explain + index scan -> bogus varno: 65001 (with some variations) |
| Previous Message | Maxim Boguk | 2011-07-03 01:23:31 | Re: BUG #6088: copy to stdout cannot be stopped with kill(pid) or pg_terminate_backend |