On 01/05/2015 05:43 PM, Peter Eisentraut wrote: > The wins on the other hand are obscure: You can now use SHOW to inspect > recovery settings. You can design your own configuration file include > structures to set them. These are not bad, but is that all?
That's not the only potential win, and it's not small either. I'll be able to tell what master a replica is replicating from using via a port 5432 connection (currently there is absolutely no way to do this). > I note that all the new settings are PGC_POSTMASTER, so you can't set > them on the fly. Changing primary_conninfo without a restart would be a > big win, for example. Is that planned? ... but there you have the flaw in the ointment. Unless we make some of the settings superuserset, no, it doesn't win us a lot, except ... > 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. -- 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
