Re: Add pg_settings.pending_restart column

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add pg_settings.pending_restart column
Date: 2015-02-17 15:45:50
Message-ID: CA+TgmoYSyQ_35gyOYA6pyrqKtDsSevZ8Yb++kcj+z_6er_4zBw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Feb 14, 2015 at 10:18 PM, Peter Eisentraut <peter_e(at)gmx(dot)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\" cannot be
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2015-02-17 15:52:55 Re: pgaudit - an auditing extension for PostgreSQL
Previous Message Petr Jelinek 2015-02-17 15:38:54 Re: Add min and max execute statement time in pg_stat_statement