Sergey Konoplev <gray.ru@gmail.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