On Wed, Mar 27, 2013 at 10:15 AM, Michael Paquier <michael.paqu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
