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.
Great!
> 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?
Oh, so that is the reason for asking about ordering. The only other
case I have seen like this is for log_statement_stats:
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("cannot enable \"log_statement_stats\" when \"log_parser_stats\",\n"
"\"log_planner_stats\", or \"log_executor_stats\" is true.")));
The code works most of the time because it is checking to see if two
values are set to non-defaults. In your case, you want to have both set
to non-defaults for it to work. I can see that requiring ordering and I
can't think of a way to fix that. If you put something in the code
after the config file was read, how do you check later for cases where
the user is using SET.
Ah, I got it. The 'source' tells you if it is coming from a config file
or from a user SET or something. You could do that check during the
assignment when it is coming from SET, and add a function call after the
config file is loaded for more global checks of multiple variables.
Anyway, we can do that later. Let's set it to false and get it in.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073