Re: sequential scans that pick up only deleted records do not honor query cancel or timeout

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: sequential scans that pick up only deleted records do not honor query cancel or timeout
Date: 2012-05-22 21:08:32
Message-ID: 8558.1337720912@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> Basically, $subject says it all. It's pretty easy to reproduce:
> delete all the records from a large table and execute any sequentially
> scanning query before autocvacuum comes around and cleans the table
> up; the query will be uncancellable. This can result in fairly
> pathological behavior in i/o constrained systems because the query
> will bog itself down writing out hint bits for minutes or hours
> without any way to cancel or effective i/o throttling (unlike vacuum).

> IMO, this should be backpatched, and is likely fixed by injecting an
> interrupts check at a strategic location. But where? I was thinking
> in heapgetpage() but here are no checks elsehwere in heapam.c which is
> a red flag.

heapgetpage() seems like the most reasonable place to me, as there we'll
only be making the check once per page not once per tuple.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message valgog 2012-05-22 21:36:23 BUG #6661: out-of-order XID insertion in KnownAssignedXids
Previous Message Robert Haas 2012-05-22 20:08:13 Re: BUG #6653: Service does not start in standby-mode