On Mon, Jan 5, 2015 at 8:43 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> 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.
But this is confusing, too, because it means that if you set a
parameter in both postgresql.conf and recovery.conf, you'll end up
with the recovery.conf value of the parameter even after recovery is
done. Until you restart, and then you won't. That's weird.
I think your idea of adding read-only GUCs with the same names as all
of the recovey.conf parameters is a clear win. Even if we do nothing
more than that, it makes the values visible from the SQL level, and
that's good. But I think we should go further and make them really be
GUCs. Otherwise, if you want to be able to change one of those
parameters other than at server startup time, you've got to invent a
separate system for reloading them on SIGHUP. If you make them part
of the GUC mechanism, you can use that. I think it's quite safe to
say that the whole reason we *have* a GUC mechanism is so that all of
our configuration can be done through one grand, unified mechanism
rather than being fragmented across many files.
Some renaming might be in order. Heikki previously suggested merging
all of the recovery_target_whatever settings down into a single
parameter recovery_target='kindofrecoverytarget furtherdetailsgohere',
like recovery_target='xid 1234' or recovery_target='name bob'. Maybe
that would be more clear (or not). Maybe standby_mode needs a better
name. But I think the starting point for this discussion shouldn't be
"why in the world would we merge recovery.conf into postgresql.conf?"
but "why, when we've otherwise gone to such trouble to push all of our
configuration through a single, unified mechanism that offers many
convenient features, do we continue to suffer our recovery.conf
settings to go through some other, less-capable mechanism?".
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company