Attached is the long-awaited guc patch that makes values fall back to their
default values when they got removed (or commented) from the configuration
file. This has always been a source of confusion.
There are three not-so-obvious cases that I'd like to comment:
First one:
In the configuration file you have:
seq_page_cost = 3 (the default for this option is 1)
You start the database and issue "SET seq_page_cost TO 4".
Then you remove the seq_page_cost definition from the configuration file and
send SIGHUP.
If you now do a "RESET seq_page_cost" it will fall back to 1 and not to 3.
Second one:
You have custom_variable_classes = "foo"
You start a transaction and do "SET foo.bar to 4".
Now you remove the custom_variable_classes definition and it falls back to
being empty. Hence all foo.* variables become invalid. You cannot COMMIT the
transaction and COMMIT results in a transaction abort.
Third one:
In the configuration file you have
custom_variable_classes = "foo"
foo.bar = 3
You start a transaction and do "SET foo.bar to 4". Then you remove the
definition of "foo.bar" but you keep the custom_variable_classes definition.
COMMITting the transaction succeeds but since foo.bar does not exist in the
configuration file anymore, your SET command is considered to define a new
variable and executing "RESET foo.bar" does not change the variable (without
any change to the configuration file it would remove your setting and
restore the setting from the configuration file for "foo.bar").
Everything else should be quite straightforward. It is also intended that if
you have changed (or commented) a variable in the configuration file that
cannot be applied (because a parameter can only be changed at server start)
you will get this message every time you send a SIGHUP. That way you can see
if your configuration file matches your current server configuration.
Comments welcome,
Joachim