Re: canceling autovacuum task woes

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: canceling autovacuum task woes
Date: 2012-07-24 19:30:49
Message-ID: 1343157963-sup-9581@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Tuesday, July 24, 2012 07:48:27 PM Robert Haas wrote:
> > I am running into a lot of customer situations where the customer
> > reports that "canceling autovacuum task" shows up in the logs, and
> > it's unclear whether this is happening often enough to matter, and
> > even more unclear what's causing it.
> >
> > Me: So, do you know what table it's getting cancelled on?
> > Customer: Nope.
> > Me: Are you running any DDL commands anywhere in the cluster?
> > Customer: Nope, absolutely none.
> > Me: Well you've got to be running something somewhere or it wouldn't
> > be having a lock conflict.
> > Customer: OK, well I don't know of any. What should I do?
> >
> > It would be awfully nice if the process that does the cancelling would
> > provide the same kind of reporting that we do for a deadlock: the
> > relevant lock tag, the PID of the process sending the cancel, and the
> > query string.

Hm, autovacuum is supposed to set an errcontext callback that would tell
you the table name it's working on at the time of the cancel. So if
even that is missing, something strange is going on.

No objections to the general idea of adding more info about the process
blocked on autovacuum.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2012-07-24 19:35:28 Re: canceling autovacuum task woes
Previous Message Merlin Moncure 2012-07-24 19:16:17 Re: [patch] libpq one-row-at-a-time API