Re: Turning recovery.conf into GUCs

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.

> 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.

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.

> In the past, when some people have complained that recovery.conf cannot
> be moved to a configuration directory, I (and others?) have argued that
> recovery.conf is really more of a command script file than a
> configuration file (that was before replication was commonplace). The
> premise of this patch is that some options really are more configuration
> than command most of the time, but that doesn't mean the old view was
> invalid.

Again, I think this ship has long since sailed.

> 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?

> 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.
b) Proper infrastructure to deal with configuration variable boundaries
and such. Just a few days ago there was e7c11887 et al.
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.

> I note that all the new settings are PGC_POSTMASTER, so you can't set
> them on the fly. Changing primary_conninfo without a restart would be a
> big win, for example. Is that planned?

I think it's not too hard to do - but I'll fight hard to do that
separately. Once we've the infrastructure I'd be surprised if took too
long to change some of them to PGC_SIGHUP.

> 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.

Well, it breaks because quoting and such is different. Otherwise I think
I agree. It allows you to keep parameters in recovery.conf if you want,
if not not.

If we add a recovery_file guc that defaults to '$PGDATA/recovery.conf'
we'd have a rather easy way to move forward imo. We can even allow two
filenames so we could default to something like
recovery_file = 'PGDATA/recovery.conf; PGDATA/recovery.trigger'

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services