From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Alex Shulgin <ash(at)commandprompt(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Turning recovery.conf into GUCs |
Date: | 2015-01-08 20:57:37 |
Message-ID: | 54AEEF41.1030802@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2015-01-08 21:01:39 | Re: Turning recovery.conf into GUCs |
Previous Message | Andres Freund | 2015-01-08 20:46:35 | Re: make check-world regress failed |