Re: guc patch: Make variables fall back to default values - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: guc patch: Make variables fall back to default values
Date
Msg-id 200702202213.l1KMDEe12578@momjian.us
Whole thread Raw
In response to guc patch: Make variables fall back to default values  (Joachim Wieland <joe@mcknight.de>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [pgsql-patches] scrollable cursor support for plpgsql
Next
From: Bruce Momjian
Date:
Subject: Re: patch adding new regexp functions