On 06/01/15 18:57, Josh Berkus wrote:
On 01/05/2015 05:43 PM, Peter Eisentraut wrote:
I have previously argued for a different approach: Ready recovery.conf
as a configuration file after postgresql.conf, but keep it as a file to
start recovery. That doesn't break any old workflows, it gets you all
the advantages of having recovery parameters in the GUC system, and it
keeps all the options open for improving things further in the future.
... and there you hit on one of the other issues with recovery.conf,
which is that it's a configuration file with configuration parameters
which gets automatically renamed when a standby is promoted. This plays
merry hell with configuration management systems. The amount of
conditional logic I've had to write for Salt to handle recovery.conf
truly doesn't bear thinking about. There may be some other way to make
recovery.conf configuration-management friendly, but I haven't thought
of it.
It hurts and it helps with config management - because right now primary
and standby can have identical postgresql.conf. Obviously if we merge
the recovery.conf settings in there then this is no longer true in the
most simple case of one conf file...I guess we can work around it using
a conf.d include dir and having the recovery specific (and any other
am-I-a-replica params) in a (lol) recovery.conf config file in there...
Cheers
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
