Re: guc patch: Make variables fall back to default values
От | Bruce Momjian |
---|---|
Тема | Re: guc patch: Make variables fall back to default values |
Дата | |
Msg-id | 200702202213.l1KMDEe12578@momjian.us обсуждение исходный текст |
Ответ на | guc patch: Make variables fall back to default values (Joachim Wieland <joe@mcknight.de>) |
Список | pgsql-patches |
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --------------------------------------------------------------------------- Joachim Wieland wrote: > 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 > [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-patches по дате отправления: