From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Joachim Wieland <joe(at)mcknight(dot)de> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: guc patch: Make variables fall back to default values |
Date: | 2007-02-20 22:13:14 |
Message-ID: | 200702202213.l1KMDEe12578@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2007-02-20 22:18:22 | Re: patch adding new regexp functions |
Previous Message | Oleg Bartunov | 2007-02-20 22:12:59 | Re: tsearch in core patch, for inclusion |