Re: [COMMITTERS] pgsql: Allow external recovery_config_directory - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [COMMITTERS] pgsql: Allow external recovery_config_directory
Date
Msg-id CA+TgmoaW5aHUSRwA5mFVJnhTY=G3xoziLkar=9Es2ogoszdpeA@mail.gmail.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Allow external recovery_config_directory  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [COMMITTERS] pgsql: Allow external recovery_config_directory  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Wed, Mar 27, 2013 at 10:15 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> Here would be the plan:
> 1) we move all the recovery parameters to GUC as proposed Masao's patch (and
> somewhat my patch now).
> 2) as default, the custom file that is used to trigger recovery is called
> recovery.conf and needs to be located in data folder. This could be the
> default value used by this feature.
> 3) When migrating to the new system, we recommend users to include
> recovery.conf with include_if_exists. Even better, we add by default an
> include_if_exists during initdb in postgresql.conf to include recovery.conf.

I don't think it's a good to call the trigger file recovery.conf.
That's just plain confusing.

There are also weird edge cases here when the server is promoted.  The
recovery.conf file won't exist any more, but the GUC settings changes
it contains will live on until the next SIGHUP.

The proposal Greg Smith floated previously, which I supported and I
believe others did as well, was to convert the parameters to GUCs, and
error out if recovery.conf existed.  That way, anyone who is doing it
wrong (for the new release), gets a clear error message.  If we were
doing that (and I had somehow thought THAT was the consensus), then
this patch is moot, because you can't set a location for recovery.conf
if that concept doesn't exist any more.  You might need a parameter to
set the location for the trigger file, perhaps.

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



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [COMMITTERS] pgsql: Allow external recovery_config_directory
Next
From: Robert Haas
Date:
Subject: Re: in-catalog Extension Scripts and Control parameters (templates?)