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