On Fri, Feb 12, 2010 at 9:14 AM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > One glaring issue with the current documentation layout is that the > documentation for the various options in recovery.conf is split in two > places.
I've been trying to explain to someone how to set this all up and they keep asking me why there's a separate recovery.conf file. I thought it made sense back when it was to control PITR and was a transient file which only applied as long as it was recovering but it seems now to have become part of the normal setup of the server. It seems like it would be much easier to keep things straight if you could set up the master and all the slaves identically and they would know when they had to store or retrieve files from the WAL archive and when they had to make or listen for streaming connections based on their master/slave status -- which is the only bit which needs to be stored outside the configuration so it can be changed dynamically. The master/slave status would be indicated by a trigger file or some external master election daemon connecting and issuing a query calling a magic sql function. But having the separate recovery.conf seems kind of pointless legacy structure at this point. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers