Peter, all: Let me go over the issues I find with recovery.conf, based on 3 aspects of my experience (1) doing DBA support (2) as a tool author (HandyRep) and (3) as a trainer, teaching new users about it. If we agree on a list of problems with the current setup (as well as a list of benefits) that's a good litmus test on whether any new version is worth adopting. Basically, new ways of doing this should remove some of the issues while not jettisoning the benefits as much as possible.
Issues: A. different formatting compared with PostgreSQL.conf, particularly quoting, and lack of support for include files. B. Inability to find out recovery.conf variables over port 5432. C. Difficulty of management due to being both a trigger file and a configuration file. D. Wierd name: for those doing only replication, not PITR, "recovery.conf" is completely baffling. E. Replication/PITR confusion: some configuration items (particularly recovery_target_*) are contradictory. F. Inability to remaster without restarting the replica. G. Inability to change parameters using ALTER SYSTEM SET. H. Requirement of being in the data directory instead of the configuration directory. I. Fairly duplicative options between pg.conf and recovery.conf (i.e. "standby_mode" vs. "hot_standby") Benefits: 1. Ability to share the exact same postgresql.conf for replica and master. 2. Easy pg_basebackup because you can exclude/generate a recovery.conf automatically. 3. Battle-tested way to make sure that replication/recovery state persists across unexpected restarts, and simple promotion workflow. -- 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
