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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers