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  <[EMAIL PROTECTED]>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

Reply via email to