Re: Turning recovery.conf into GUCs

I think this is a valuable effort, but I wonder how we are going to
arrive at a consensus.  I don't see any committer supporting these
changes. Clearly, there are some advantages to having recovery
parameters be GUCs, but the proposed changes also come with some
disadvantages, and the tradeoffs aren't so clear.

For example, putting recovery target parameters into postgresql.conf
might not make sense to some people.  Once you have reached the recovery
end point, the information is obsolete.  Keeping it set could be
considered confusing.

Moreover, when I'm actually doing point-in-time-recovery attempts, I
don't think I want to be messing with my pristine postgresql.conf file.Having those settings separate isn't a bad idea
inthat case.
 

Some people might like the recovery.done file as a historical record.
Having standby.enabled just be deleted would destroy that information
once recovery has ended.

In the past, when some people have complained that recovery.conf cannot
be moved to a configuration directory, I (and others?) have argued that
recovery.conf is really more of a command script file than a
configuration file (that was before replication was commonplace).  The
premise of this patch is that some options really are more configuration
than command most of the time, but that doesn't mean the old view was
invalid.

The current system makes it easy to share postgresql.conf between
primary and standby and just maintain the information related to the
standby locally in recovery.conf.  pg_basebackup -R makes that even
easier.  It's still possible to do this in the new system, but it's
decidedly more work.

These are all "soft" reasons, but they add up.

The wins on the other hand are obscure: You can now use SHOW to inspect
recovery settings.  You can design your own configuration file include
structures to set them.  These are not bad, but is that all?

I note that all the new settings are PGC_POSTMASTER, so you can't set
them on the fly.  Changing primary_conninfo without a restart would be a
big win, for example.  Is that planned?

It might be acceptable to break all the old workflows if the new system
was obviously great, but it's not.  It's still confusing as heck.  For
example, we would have a file "standby.enabled" and a setting
"standby_mode", which would mean totally different things.  I think
there is also some conceptual overlap between standby_mode and
recovery_target_action (standby_mode is really something like
recovery_target_action = keep_going).  I also find the various uses of
"trigger file" or "to trigger" confusing.  The old trigger file to
trigger promotion makes sense.  But calling "standby.enabled" a trigger
file as well confuses two entirely different concepts.

I have previously argued for a different approach: Ready recovery.conf
as a configuration file after postgresql.conf, but keep it as a file to
start recovery.  That doesn't break any old workflows, it gets you all
the advantages of having recovery parameters in the GUC system, and it
keeps all the options open for improving things further in the future.