Peter Eisentraut wrote:
> Matthew T. O'Connor wrote:
> > I think it's ready to apply barring any feedback to the contrary.
> > Actually I do have a small improvement I will send in tomorrow (sorry
> > can't do it any sooner) that defaulted autovac_enabled to false, and
> > makes autovac fail more gracefully when the stats system is not
> > enabled, but that shouldn't stop you from applying this patch.
> 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. :-)
> > The thing I was trying to do was use the GUC hook function to make
> > sure that the required GUC variables are also set before GUC reports
> > autovac as enabled. This seemed cleaner to me, but apparently it
> > won't work since it seems that autovac_enabled is read from GUC
> > before the stats variables, and there is no way to force the order in
> > which they are read. Am I missing something?
> 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.
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster