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

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

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-07-24 20:09:41
Subject: Re: canceling autovacuum task woes
Previous:From: Alvaro HerreraDate: 2012-07-24 20:03:39
Subject: Re: canceling autovacuum task woes

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