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