Greetings,
* Michael Paquier (michael@paquier.xyz) wrote:
> On Mon, Nov 26, 2018 at 02:06:36PM +0100, Peter Eisentraut wrote:
> > What is the reason for allowing multiple recovery_target_* settings and
> > taking the last one?
>
> This came originally to check that recovery.conf handles correctly its
> recovery targets when multiple ones are defined with the last one
> winning, as users may want to append additional targets in an existing
> recovery.conf. I have not checked the code in details, but I think that
> we should be careful to keep that property, even with EXEC_BACKEND.
Ugh, no, I don't agree that this property makes sense to keep and since
we're making these changes, I'd argue that it's exactly the right time
to do away with that.
I would think we'd have the different GUCs and then the check functions
would only validate that they're valid inputs and then when we get to
the point where we're starting to do recovery we check and make sure
we've been given a sane overall configuration- which means that only
*one* is set, and it matches the recovery target requested.
As with backup, recovery should be extremely clear and straight-forward,
with alarms going off if there's something unclear or inconsistent. One
of the arguments around using postgresql.auto.conf (or any other managed
config file, as discussed elsewhere) is that it can be machine-processed
and therefore tooling around it can make sure that what goes into that
file is correct and sane and doesn't need to rely on being able to just
append things to the file and hope that it works.
Thanks!
Stephen