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?

Search Discussions

  • Tom Lane at Mar 7, 2006 at 3:10 am

    "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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMar 6, '06 at 7:58p
activeMar 7, '06 at 3:10a
posts2
users2
websitepostgresql.org...
irc#postgresql

2 users in discussion

Tom Lane: 1 post Markus Bertheau: 1 post

People

Translate

site design / logo © 2021 Grokbase