Re: Add pg_settings.pending_restart column - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Add pg_settings.pending_restart column
Date
Msg-id CA+TgmoYSyQ_35gyOYA6pyrqKtDsSevZ8Yb++kcj+z_6er_4zBw@mail.gmail.com
Whole thread Raw
In response to Add pg_settings.pending_restart column  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Add pg_settings.pending_restart column
List pgsql-hackers
On Sat, Feb 14, 2015 at 10:18 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> When managing configuration changes through automatic systems like Chef
> or Puppet, there is a problem: How do you manage changes requiring a
> restart?
>
> Generally, you'd set it up so that when a configuration file is changed,
> the server is reloaded.  But for settings that require a restart, well,
> I don't know.  From discussions with others, it emerged that a way to
> ask the server whether a restart is necessary would be useful.  Then you
> can either automate the restart, or have a monitoring system warn you
> about it, and possibly schedule a restart separately or undo the
> configuration file change.
>
> So here is a patch for that.  It adds a column pending_restart to
> pg_settings that is true when the configuration file contains a changed
> setting that requires a restart.  We already had the logic to detect
> such changes, for producing the log entry.  I have also set it up so
> that if you change your mind and undo the setting and reload the server,
> the pending_restart flag is reset to false.

You don't really need the "else" here, and in parallel cases:
                    if (*conf->variable != newval)                    {
+                        record->status |= GUC_PENDING_RESTART;                        ereport(elevel,
             (errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),                                 errmsg("parameter \"%s\"
cannotbe
 
changed without restarting the server",                                        name)));                        return
0;                   }
 
+                    else
+                        record->status &= ~GUC_PENDING_RESTART;                    return -1;

The if-statement ends with "return 0" so there is no reason for the "else".

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: Add min and max execute statement time in pg_stat_statement
Next
From: Stephen Frost
Date:
Subject: Re: pgaudit - an auditing extension for PostgreSQL