Hello, I spent some time thinking about this issue and the proposed patch, and I wonder if we can simplify it a bit further.
If we don't want to rely on GUC hooks for cross-checking multiple recovery target settings, perhaps the assign hooks could stop updating the shared recoveryTarget state altogether and only maintain their own underlying variables. As far as I can tell, the existing recovery target variables already seem sufficient to determine whether each target is configured. The only exception appears to be recovery_target = 'immediate', which would probably need an additional boolean flag (or similar state) to represent whether it has been specified. Then validateRecoveryParameters() could determine which recovery target is configured by inspecting those variables directly, report an error if more than one target is set, and reconstruct the same recoveryTarget state that the current code expects. Does that make sense? Regards, -- Kyotaro Horiguchi NTT Open Source Software Center
