Re: [COMMITTERS] pgsql: Allow external recovery_config_directory

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Allow external recovery_config_directory
Date: 2013-03-27 14:26:56
Message-ID: CA+TgmoaW5aHUSRwA5mFVJnhTY=G3xoziLkar=9Es2ogoszdpeA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Wed, Mar 27, 2013 at 10:15 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Michael Paquier 2013-03-27 14:37:54 Re: [COMMITTERS] pgsql: Allow external recovery_config_directory
Previous Message Heikki Linnakangas 2013-03-27 14:20:45 Re: [COMMITTERS] pgsql: Allow external recovery_config_directory

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-03-27 14:28:40 Re: in-catalog Extension Scripts and Control parameters (templates?)
Previous Message Tom Lane 2013-03-27 14:20:46 Re: Default connection parameters for postgres_fdw and dblink