"Markus Bertheau" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
