Re: Changing recovery.conf parameters into GUCs - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Changing recovery.conf parameters into GUCs
Date
Msg-id CA+U5nM+o6fe=wMCKNZq-ANj9bHgy3YefAi5wND44RiqgJfceJA@mail.gmail.com
Whole thread Raw
In response to Re: Changing recovery.conf parameters into GUCs  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Changing recovery.conf parameters into GUCs  (Michael Paquier <michael.paquier@gmail.com>)
Re: Changing recovery.conf parameters into GUCs  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On 29 March 2013 01:17, Michael Paquier <michael.paquier@gmail.com> wrote:

> The main argument on which this proposal is based on is to keep
> backward-compatibility.

The main objective is to get recovery parameters as GUCs, as I said....

> On Fri, Mar 29, 2013 at 12:48 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> What we want to do is make recovery parameters into GUCs, allowing
>> them to be reset by SIGHUP and also to allow all users to see the
>> parameters in use, from any session.

From the user's perspective, we are making no changes. All recovery
parameters will work exactly the same as they always did, just now we
get to see their values more easily and we can potentially place them
in a different file if we wish. The user will have no idea that we
plan to do some internal refactoring of how we process the parameters.
So IMHO simplicity means continuing to work the way it always did
work. We simply announce "PostgreSQL now supports configuration
directories. All parameters, including recovery parameters, can be
placed in any configuration file, or in $PGDATA/recovery.conf, as
before".

We introduced "pg_ctl promote" with a new API without removing
existing ones, and some people are still in favour of keeping both
APIs. Doing the same thing here makes sense and reduces conceptual
change.

Early discussions had difficulties because of the lack of config
directories, include_if_exists and this patch. We now have the
technical capability to meet every request. Circumstances have changed
and outcomes may change also.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Performance Improvement by reducing WAL for Update Operation
Next
From: Michael Paquier
Date:
Subject: Re: Changing recovery.conf parameters into GUCs