On 11/01/13 03:23, Kevin Grittner wrote:
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
Thanks for all the replies. I'm pretty sure right now, it is the pgpool
since I searched the pgpool source codes and found those strings.
Also, I have the pgpool configuration 'insert_lock' on (by default),
but without applying the 'insert_lock.sql' as pgpool suggested.
However, I don't know why it did not happen before. By the way,
I think Kevin is right, since the problem happened to our test instance
also and it is with postgres 9.2.4.
For pgpool, if anyone knows that if I can apply the 'insert_lock.sql' when
the pgpool is still running (maybe I should ask this in pgpool groups) ?
Thanks,
Gary
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
