Re: Vacuum as "easily obtained" locks - Mailing list pgsql-general

From Scott Marlowe
Subject Re: Vacuum as "easily obtained" locks
Date
Msg-id CAOR=d=152Sr4CwL_710WnAo97HVTvsKKkOPn=P=uSKCCZwFD4w@mail.gmail.com
Whole thread Raw
In response to Re: Vacuum as "easily obtained" locks  (Michael Graham <mgraham@bloxx.com>)
List pgsql-general
On Wed, Aug 3, 2011 at 8:57 AM, Michael Graham <mgraham@bloxx.com> wrote:
> On Wed, 2011-08-03 at 10:17 -0400, Tom Lane wrote:
>> Michael Graham <mgraham@bloxx.com> writes:
>> > Would my applications
>> > constant polling of the queue mean that the lock could not be easily
>> > obtained?
>>
>> Very possible, depending on what duty cycle is involved there.
>
> Hmm.  The clients aren't that aggressive, especially when they failed to
> find data on a previous select, there are 4 clients, they each poll
> every 10 seconds and the select runs in <1ms.
>
> It might be worth noting that they don't ever disconnect from the
> server, but I assume that is not an issue for getting the
> AccessExclusiveLock on the table?
>
> My worry at the moment is that because the table is so large the vacuum
> takes a very long time to run (one has been running for 5hrs) and I
> assume it will continue to run until it is able to get the
> AccessExclusiveLock is so desperately wants.

Assuming you have the spare IO look at making autovacuum more
aggressive.   Reduce naptime and increase cost

pgsql-general by date:

Previous
From: Pavan Deolasee
Date:
Subject: Re: Vacuum as "easily obtained" locks
Next
From: Bill Moran
Date:
Subject: Re: Vacuum as "easily obtained" locks