On Fri, Feb 12, 2010 at 9:14 AM, Heikki Linnakangas
<heikki.linnakangas@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
