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                        |
  [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

Reply via email to