Re: autovaccum task got cancelled

Sergey Konoplev <gray(dot)ru(at)gmail(dot)com> wrote:

>> As far as I know, the application programs do not make any
>> specific lock on the 'file' table.  I'm not sure if it is caused
>> by the pgpool or something else.
>
> [...]
>
>> 2013-10-31 18:01:30 UTCLOG:  sending cancel to blocking autovacuum PID 8614
>> 2013-10-31 18:01:30 UTCDETAIL:  Process 8677 waits for ShareRowExclusiveLock on relation 11959608 of database 596746.
>> 2013-10-31 18:01:30 UTCSTATEMENT:  LOCK TABLE "file" IN SHARE ROW EXCLUSIVE MODE
>> 2013-10-31 18:01:30 UTCERROR:  canceling autovacuum task
>> 2013-10-31 18:01:30 UTCCONTEXT:  automatic vacuum of table "sd3ops1.public.file"
>
> From the release notes to 9.0.12:
>
> <<Fix performance problems with autovacuum truncation in busy
> workloads (Jan Wieck)

I don't think the problem described here has anything to do with
that.  It looks to me like there is an explicit LOCK TABLE
statement being executed for a mode which conflicts with a normal
vacuum or analyze, even without truncation.  The cited change
*avoids* this sort of cancellation for the truncation phase, so it
is not getting that far.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company