On 2020-Feb-27, Peter Eisentraut wrote: > So this patch relaxes this a bit. Upon receipt of > XLOG_PARAMETER_CHANGE, we still check the settings but only issue a > warning and set a global flag if there is a problem. Then when we > actually hit the resource issue and the flag was set, we issue another > warning message with relevant information. Additionally, at that > point we pause recovery, so a hot standby remains usable.
Hmm, so what is the actual end-user behavior? As I read the code, we first send the WARNING, then pause recovery until the user resumes replication; at that point we raise the original error. Presumably, at that point the startup process terminates and is relaunched, and replay continues normally. Is that it? I think if the startup process terminates because of the original error, after it is unpaused, postmaster will get that as a signal to do a crash-recovery cycle, closing all existing connections. Is that right? If so, it would be worth improving that (possibly by adding a sigsetjmp() block) to avoid the disruption. Thanks, -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
