Re: Turning recovery.conf into GUCs

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