Re: Turning recovery.conf into GUCs

On 14/01/15 14:24, Robert Haas wrote:
> 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.

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