Re: canceling autovacuum task woes

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: canceling autovacuum task woes
Date: 2012-07-24 20:07:44
Message-ID: CA+Tgmoar5d+WMTgg1X8dfkzDyiLZyT=kXwMxgVPQay2h_Y4XSw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 24, 2012 at 4:03 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Excerpts from Robert Haas's message of mar jul 24 15:52:23 -0400 2012:
>> On Tue, Jul 24, 2012 at 3:35 PM, Alvaro Herrera
>> <alvherre(at)commandprompt(dot)com> wrote:
>> > Yep, it says:
>> >
>> > ERROR: canceling autovacuum task
>> > CONTEXT: automatic vacuum of table "alvherre.public.foo"
>> >
>> > So at least that part seems pilot error more than anything else.
>>
>> Yeah, you're right. So you do get the table name. But you don't get
>> the cause, which is what you really need to understand why it's
>> happening. Attached is a patch that adds some more detail. Here's an
>> example of what the output looks like:
>>
>> LOG: sending cancel to blocking autovacuum PID 21595
>> DETAIL: Process 21618 waits for AccessExclusiveLock on relation 27863
>> of database 16384
>> STATEMENT: drop table if exists pgbench_accounts
>> ERROR: canceling autovacuum task
>> CONTEXT: automatic vacuum of table "rhaas.public.pgbench_accounts"
>
> 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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-07-24 20:09:41 Re: canceling autovacuum task woes
Previous Message Alvaro Herrera 2012-07-24 20:03:39 Re: canceling autovacuum task woes