Re: pg_autovacuum integration attempt #2 - Mailing list pgsql-patches

From Matthew T. O'Connor
Subject Re: pg_autovacuum integration attempt #2
Date
Msg-id 1090043327.31080.4.camel@zedora2
Whole thread Raw
In response to Re: pg_autovacuum integration attempt #2  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: pg_autovacuum integration attempt #2
Re: pg_autovacuum integration attempt #2
Re: pg_autovacuum integration attempt #2
List pgsql-patches
On Fri, 2004-07-16 at 17:13, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > A nitpick on that parameter name:  There is not reason to abbreviate
> > "autovacuum": there is enough space.  And the "_enabled" is redundant.
>
> Agreed.  Nitpicks are important too because it makes us so beautiful.  :-)

:-) I'll make that change.

> > What I am missing at least is what you really mean by "the required GUC
> > variables are also set".  GUC variables are always set to something (at
> > least after the initialization phase, but you don't get to do anything
> > with GUC before the initialization, obviously).
>
> He means he has to have the stats collector enabled along with
> autovacuum, and he doesn't have a way to effectively test that stats are
> enabled when enabling autovacuum because the ordering of postgresql.conf
> variable loads isn't predefined.

Exactly.  However, I can work around the GUC ordering issue just by
having the postmaster check all the required variables before launching
autovac.  What I wanted to do was have GUC prevent autovacuum = true
when the stats collector is not enabled, reguardless of what is in
postgresql.conf.


pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: initdb authentication
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: pg_autovacuum integration attempt #2