Re: Turning recovery.conf into GUCs

Jaime,

>> Except that we'll want 9.4's -R to do something, probably create a file
>> called conf.d/replication.conf. Mind you, it won't need the same wonky
>> quoting stuff.
>>
>
> Currently the patch uses -R to create the recovery trigger file

Right, I'm saying that we'll want to do better than that for release,
but that's dependant on committing the conf directory patch.

Note that this change makes committing the conf.d patch extra-important;
it's going to be a LOT easier to upgrade tools for 9.4 if we have that.

> well, after upgrade you should do checks. and even if it happens,
> after it happens once people will be aware of the change.
> now, some suggestions were made to avoid the problem. 1) read the file
> if exists last in the process of postgresql.conf, 2) add a GUC
> indicating if it should read it and include it (not using it as a
> trigger file). another one, 3) include in this release an
> include_if_exists directive and give a warning if it sees the file
> then include it, on next release remove the include_if_exists (at
> least that way people will be warned before breaking compatibility)

I think all of these suggestions just make our code more complicated
without improving the upgrade situation.

The reason given (and I think it's pretty good) for erroring on
recovery.conf is that we don't want people to accidentally take a server
out of replication because they didn't check which version of PostgreSQL
they are on.

>> *on the other hand*, if we prevent creation of a configuration file
>> named "recovery.conf", then we block efforts to write
>> backwards-compatible management utilities.
>>
>
> and all tools and procedures that currently exists.

Right. However, exploring your suggestions above, none of those
workarounds prevent breakage. And in some cases, they make the breakage
less obvious than the current patch does. If repmgr 1.2 / OmniPITR 1.2
won't work correctly with 9.4, then we want those tools to break at
upgrade time, not later when the user is trying to fail over.

For that matter, 9.4 is a very good time (relatively speaking) to break
replication tools because the new logical replication is going to cause
everyone to rev their tools anyway.

This kind of breakage alone might end up being a good reason to call the
next version 10.0.

> well, there should be good solutions... maybe we haven't thought them yet.
> anyway, we can't postpone the decision forever. we need to make a
> decision and stick with it otherwise this patch will be stalled N
> releases for no good reason

I think if there were a good solution, sometime in the last 1.5 years
someone would have suggested it. Gods know Simon has tried.

> exactly as it is now, if it sees the recovery trigger file, then it
> starts ArchiveRecovery and after it finish delete the file (the only
> difference) and increment the timeline

OK, so if I'm doing a PITR recovery, I just put the recovery variables
into postgresql.conf, then?

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com