On Fri, May 14, 2010 at 6:41 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> The main reason for having a separate recovery.conf file is that its
>> existence is what drives the setting of InArchiveRecovery. If we were
>> to devise some other trigger for that condition, it'd be possible to
>> fold all those settings in as GUC variables.
>
> And the removal of recovery.conf at end of recovery prevents the
> re-entry into archive recovery if we crash.
These things made sense when we were only dealing with PITR recovery
from a backup intending to bring up the database when the PITR reached
the target. That's now only one specific use case. For hot standbys we
don't want them to come up ever, even if we crash. And for other
standby databases we probably want to control this manually, not
automatically.
In these cases it's really confusing for users that some parameters
have to be in postgresql.conf and some in recovery.conf. They don't
see any distinction between these two files since they don't intend to
ever see the case where the target is reached and the file moved out
of the way automatically.
My suggestion is we should fold all the parameters into
postgresql.conf and treat recovery.conf as an additional
postgresql.conf to read. It would allow any GUC. The only difference
is that it would be moved out of the way automatically when the target
is reached.
Ideally I would have all the configuration be in postgresql.conf and
be identical between all servers, masters and slaves. The only
difference would be a single line which controlled whether to push or
pull wal data. Switching roles would be a regular GUC change in
postgresql.conf and pg_ctl reload.
--
greg