Greetings, * Michael Paquier (mich...@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
signature.asc
Description: PGP signature
