Re: Turning recovery.conf into GUCs

On 1/6/15 8:08 PM, Andres Freund wrote:
> On 2015-01-05 20:43:12 -0500, Peter Eisentraut wrote:
>> 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.
> 
> I don't know, but I think that ship has sailed. hot_standby,
> archive_command, archive_mode, hot_standby_feedback are all essentially
> treated differently between primary and standby.

I don't mind those.  I mean things like recovery_target_time.

>> 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 in that case.
> 
> Well, nothing stops you from having a include file or something similar.

Sure, I need to update postgresql.conf to have an include file.

> I think we should just make recovery.conf behave exactly the way it does
> right now, except parse it according to guc rules. That way the changes
> when migrating are minimal and we don't desupport any
> usecases. Disallowing that way of operating just seems like
> intentionally throwing rocks in the way of getting this done.

That was more or less my proposal.

>> 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.
> 
> Really? Howso?

You have to set up include files, override the include file on the
standby, I don't know how pg_basebackup -R would even work.  And most
importantly, you have to come up with all of that yourself, instead of
it just working.

>> 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?
> 
> It's much more:
> a) One configuration format instead of two somewhat, but not really,
>    similar ones.

Agreed, but that's also fixable by just changing how recovery.conf is
parsed.  It doesn't require user space changes.

> b) Proper infrastructure to deal with configuration variable boundaries
>    and such. Just a few days ago there was e7c11887 et al.

That's just an implementation issue.

> c) Infrastructure for changing settings effective during recovery. Right
>    now we'd have to rebuild a lot of guc infrasturcture to allow
>    that. It'd not be that hard to allow changing parameters like
>    restore_command, primary_conninfo, recovery_target_* et al. That's
>    for sure not the same commit, but once the infrastructure is in those
>    won't be too hard.

Right, if that worked, then it would be a real win.  But this discussion
is about right now, and the perspective of the user.