On 14/01/15 14:24, Robert Haas wrote:
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.
This is basically what the patch which is in commitfest does no?
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).
I was thinking about this a lot myself while reviewing the patch too,
seems strange to have multiple config parameters for what is essentially
same thing, my thinking was similar except I'd use ":" as separator
('kindofrecoverytarget:furtherdetailsgohere'). I think though while it
is technically nicer to do this, it might hurt usability for users.
Maybe standby_mode needs a better name.
I actually think standby_mode should be merged with hot_standby (as in
standby_mode = 'hot'/'warm'/'off' or something).
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?".
+1
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
