On Mon, Jan 5, 2015 at 8:43 PM, Peter Eisentraut <pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
