Re: canceling autovacuum task woes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: canceling autovacuum task woes
Date
Msg-id 27169.1343161862@sss.pgh.pa.us
Whole thread Raw
In response to Re: canceling autovacuum task woes  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: canceling autovacuum task woes  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jul 24, 2012 at 4:03 PM, Alvaro Herrera
> <alvherre@commandprompt.com> wrote:
>> Looks great.  Are you considering backpatching this?

> Well, that would certainly make MY life easier.  I am not sure whether
> it would be in line with project policy, however.

+1 for a backpatch.  Otherwise it'll be years before we gain any
information about the unexpected cancels that you think exist.

However, after looking some more at deadlock.c, I wonder whether
(a) this patch gives sufficient detail, and (b) whether there isn't a
problem that's obvious by inspection.  It appears to me that as the
blocking_autovacuum_proc stuff is coded, it will finger an AV proc as
needing to be killed even though it may be several graph edges out from
the current proc.  This means that with respect to (a), the connection
from the process doing the kill to the AV proc may be inadequately
documented by this patch, and with respect to (b), there might well be
cases where we found an AV proc somewhere in the graph traversal but
it's not actually guilty of blocking the current process ... especially
not after the queue reorderings that we may have done.  I think I'd be
happier with that code if it restricted its AV targets to procs that
*directly* block the current process, which not incidentally would make
this amount of log detail sufficient.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Marko Kreen
Date:
Subject: Re: [patch] libpq one-row-at-a-time API
Next
From: Alvaro Herrera
Date:
Subject: Re: CHECK NO INHERIT syntax