On 4/22/15 2:32 AM, Michael Paquier wrote:
> Attached is a rebased patch with previous comments addressed as I was
> looking at it.
> Switching this patch as "Ready for committer".
Committed, thanks.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Thu, Mar 5, 2015 at 12:04 PM, Peter Eisentraut wrote:
> On 2/17/15 10:45 AM, Robert Haas wrote:
>> You don't really need the "else" here, and in parallel cases:
>>
>> if (*conf->variable != newval)
>> {
>> +record->status |= GUC_
On 2/15/15 3:41 AM, David G Johnston wrote:
> Otherwise it seems fine but I cannot help but feel that false positives are
> possible; though nothing that doesn't already exist. Mainly, is the change
> going to end up only affect the reset or default value but not the currently
> active value?
I d
On 2/17/15 10:45 AM, Robert Haas wrote:
> You don't really need the "else" here, and in parallel cases:
>
> if (*conf->variable != newval)
> {
> +record->status |= GUC_PENDING_RESTART;
> ereport(elevel,
>
On Sat, Feb 14, 2015 at 10:18 PM, Peter Eisentraut 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 s
Peter Eisentraut-2 wrote
> 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
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 d
