Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group