Hi, all

Recently, I got a problem that the startup process of standby is stuck and 
keeps in a waiting state. The backtrace of startup process shows that it is 
waiting for a backend process which conflicts with recovery processing to exit, 
 the guc parameters max_standby_streaming_delay and max_standby_archive_delay 
are both set as 30 seconds, but it doesn't work. The backend process keeps 
alive, and the backtrace of this backend process show that it is waiting for 
the socket to be writeable in secure_write(). After further reading the code, I 
found that ProcessClientWriteInterrupt() in secure_write() only process 
interrupts when ProcDiePending is true, otherwise do nothing. However, snapshot 
conflicts with recovery will only set QueryCancelPending as true, so the 
response to the signal will de delayed indefinitely if the corresponding client 
is stuck, thus blocking the recovery process.

I want to know why the interrupt is only handled when ProcDiePending is true, I 
think query which is supposed to be canceled also should respond to the signal.

I also want to share a patch with you, I add a guc parameter 
max_standby_client_write_delay, if a query is supposed to be canceled, and the 
time delayed by a client exceeds max_standby_client_write_delay, then set 
ProcDiePending as true to avoid being delayed indefinitely, what do you think 
of it, hope to get your reply.

Thanks & Best Regard

Attachment: 0001-Set-max-client-write-delay-timeout-for-query-which-i.patch
Description: Binary data

Reply via email to