> 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@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support