Обсуждение: Plan for resetting commented postgresql.conf vars at sighup

Hi,

this is the plan: In ParseConfigFile, record the fact that the
variable was set in response to SIG_HUP in the status field
(GUC_SET_FROM_SIGHUP). After setting all variables in postgresql.conf,
set all variables that can appear in postgresql.conf
(GUC_DISALLOW_IN_FILE), don't have their built-in value still set
(PGC_S_DEFAULT), may be set from postgresql.conf (context not INTERNAL
or POSTMASTER) and weren't set from SIGHUP (GUC_SET_FROM_SIGHUP) to
their built-in default value.

One problem is that set_config_option takes the variable's new value
as a string, and at the moment the built-in values are saved with
their real type (int, bool or double), so I can't call
set_config_option with them. So I want to save the boot_val in
config_generic as a string instead of in config_/type/ as their real
type and change InitializeGUCOptions to set the initial reset_val from
the string in boot_val.

Any flaws?

"Markus Bertheau" <mbertheau.pg@googlemail.com> writes:
> this is the plan: In ParseConfigFile, record the fact that the
> variable was set in response to SIG_HUP in the status field
> (GUC_SET_FROM_SIGHUP). After setting all variables in postgresql.conf,
> set all variables that can appear in postgresql.conf
> (GUC_DISALLOW_IN_FILE), don't have their built-in value still set
> (PGC_S_DEFAULT), may be set from postgresql.conf (context not INTERNAL
> or POSTMASTER) and weren't set from SIGHUP (GUC_SET_FROM_SIGHUP) to
> their built-in default value.

This seems pretty nonrobust, in particular if there's an elog partway
through you will be left with very messed-up state (all the wrong things
will happen next time).  Might help to keep the "needs reset" state in
temporary memory instead of the status fields.

> One problem is that set_config_option takes the variable's new value
> as a string,

You should not be thinking in terms of doing this through
set_config_option (its API does not offer any way to reset to default).
So I don't really see the issue here.
        regards, tom lane