Re: Autovacuum firing up during my manual vacuum on same table

From: "Henry C(dot)" <henka(at)cityweb(dot)co(dot)za>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Autovacuum firing up during my manual vacuum on same table
Date: 2011-04-03 10:03:39
Message-ID: b44a031ccaf39350744f158088a32ce1.squirrel@zenmail.co.za
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sat, April 2, 2011 22:30, Tom Lane wrote:
>> Have you tried upping the aggressiveness of autovacuum?
>>
>
> I'm wondering about poor selection of the cost_delay settings in
> particular. It's quite easy to slow autovacuum to the point that it takes
> forever to do anything.

It's been on the default 20ms. Now giving 0 a try. In our app responsiveness
is less of a concern since we don't have human interaction. Reliability is a
greater concern.

> It's also possible that Henry is getting bit by the bug fixed here:
>
>
> Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> Branch: master [b58c25055] 2010-11-19 22:28:20 -0500
> Branch: REL9_0_STABLE Release: REL9_0_2 [b5efc0940] 2010-11-19 22:28:25 -0500
> Branch: REL8_4_STABLE Release: REL8_4_6 [fab2af30d] 2010-11-19 22:28:30 -0500
> Branch: REL8_3_STABLE Release: REL8_3_13 [6cb9d5113] 2010-11-19 22:28:35 -0500
>
>
> Fix leakage of cost_limit when multiple autovacuum workers are active.

I'm using 9.0.3, and typically (when things eventually deteriorate to a
impending-wraparound situation) there are at least 2 and sometimes a few more
autovac procs running - some of them for weeks).

Anyway, time will now tell whether a cost_delay of 0 and some more SSDs will
help prevent hitting the wraparound wall.

Cheers
h

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Thomas Kellerer 2011-04-03 13:34:23 Re: Table lock while adding a column and clients are logged in
Previous Message Alban Hertroys 2011-04-03 09:31:02 Re: Table lock while adding a column and clients are logged in