On 11/01/13 03:23, Kevin Grittner wrote:
> 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
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
