On 01/06/2015 01:22 PM, Peter Eisentraut wrote:
> That said, there is a much simpler way to achieve that specific
> functionality: Expose all the recovery settings as fake read-only GUC
> variables. See attached patch for an example.
I have no objections to that idea in principle. As long as it gets into
9.5.
> Btw., I'm not sure that everyone will be happy to have primary_conninfo
> visible, since it might contain passwords.
Didn't we discuss this? I forgot what the conclusion was ... probably
not to put passwords in primary_conninfo.
>
>> ... 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.
>
> I have written similar logic, and while it's not pleasant, it's doable.
> This issue would really only go away if you don't use a file to signal
> recovery at all, which you have argued for, but which is really a
> separate and more difficult problem.
As far as CMSes are concerned, there is a vast difference between a file
which contains configuration variables and one which does not. That is,
an *empty* recovery.conf file which just signals the start of recovery
is not a configuration problem. The problem comes in in that
recovery.conf serves two separate purposes: it's a configuration file,
and it's also a trigger file.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com