Re: canceling autovacuum task woes

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: canceling autovacuum task woes
Дата
Msg-id 27169.1343161862@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: canceling autovacuum task woes  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: canceling autovacuum task woes  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Marko Kreen
Дата:
Сообщение: Re: [patch] libpq one-row-at-a-time API
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: CHECK NO INHERIT syntax