On Wed, Oct 02, 2019 at 03:30:38AM -0400, Stephen Frost wrote:
> * David Steele (david@pgmasters.net) wrote:
>> On 9/28/19 1:26 PM, Fujii Masao wrote:
>>> There might be some recovery parameters that we can safely use
>>> even in crash recovery, e.g., maybe recovery_end_command
>>> (now, you can see that recovery_end_command is executed in
>>> crash recovery in v12). But at this stage of v12, it's worth thinking to
>>> just cause crash recovery to exit with an error when any recovery
>>> parameter is set. Thought?
>>
>> I dislike the idea of crash recovery throwing fatal errors because there
>> are recovery settings in postgresql.auto.conf. Since there is no
>> defined mechanism for cleaning out old recovery settings we have to
>> assume that they will persist (and accumulate) more or less forever.
Yeah, I don't think that's a good thing either. That's a recipe to
make the user experience more confusing.
>>> Or if that change is overkill, alternatively we can make crash recovery
>>> "ignore" any recovery parameters, e.g., by forcibly disabling
>>> the parameters.
>>
>> I'd rather load recovery settings *only* if recovery.signal or
>> standby.signal is present and do this only after crash recovery is
>> complete, i.e. in the absence of backup_label.
>>
>> I think blindly loading recovery settings then trying to ignore them
>> later is pretty much why we are having these issues in the first place.
>> I'd rather not extend that pattern if possible.
>
> Agreed.
That would mean that you need to create some new special handling,
while making sure that the process reading the parameters is not
confused either by default values. It seems to me that if we are not
in recovery, the best thing was can do now is just to not process
anything those parameters trigger, instead of "ignoring" these (you
are referring to use SetConfigOption in the startup process here?).
--
Michael
