Re: Turning recovery.conf into GUCs

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.

In response to

Responses

Browse pgsql-hackers by date

  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