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.
Advertising
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
