Sergey Konoplev <gray.ru@xxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
