guc patch: Make variables fall back to default values
От | Joachim Wieland |
---|---|
Тема | guc patch: Make variables fall back to default values |
Дата | |
Msg-id | 20070219130748.GA4994@mcknight.de обсуждение исходный текст |
Ответы |
Re: guc patch: Make variables fall back to default
values
Re: guc patch: Make variables fall back to default values Re: guc patch: Make variables fall back to default values |
Список | pgsql-patches |
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
Вложения
В списке pgsql-patches по дате отправления: