Re: guc patch: Make variables fall back to default values

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. +

In response to

Browse pgsql-patches by date

  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