Fujii Masao <masao.fujii@gmail.com> writes:
>> Agreed. Seems like that could be added to the patch above easily
>> enough. More checks would be needed to prevent the behaviors I've been
>> seeing in the other thread, but it should be possible to more or less
>> mimic the old behavior with sufficient checks.
> Yeah, more checks would be necessary. IMO easy fix is to forbid not only
> recovery target parameters but also any recovery parameters (specified
> in recovery.conf in previous versions) in crash recovery.
> In v11 or before, any parameters in recovery.conf cannot take effect in
> crash recovery because crash recovery always starts without recovery.conf.
> But in v12, those parameters are specified in postgresql.conf,
> so they may take effect even in crash recovery (i.e., when both
> recovery.signal and standby.signal are missing). This would be the root
> cause of the problems that we are discussing, I think.
So ... what I'm wondering about here is what happens during *actual* crash
recovery, eg a postmaster-driven restart of the startup process after
a backend crash in hot standby. The direction you guys are going in
seems likely to cause the startup process to refuse to function until
those parameters are removed from postgresql.conf, which seems quite
user-unfriendly.
Maybe I'm misunderstanding, but I think that rather than adding error
checks that were not there before, the right path to fixing this is
to cause these settings to be ignored if we're doing crash recovery.
Not make the user take them out (and possibly later put them back).
regards, tom lane