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