On Mon, Oct 21, 2019 at 11:08 AM Pavel Stehule <pavel.steh...@gmail.com> wrote: > > po 21. 10. 2019 v 7:11 odesÃlatel Amit Kapila <amit.kapil...@gmail.com> > napsal: >> >> >(under low load (only pg_sleep was called). >> > >> >> I guess this is also possible because immediately after >> TerminateOtherDBBackends, we call CountOtherDBBackends which again >> give 5s to allow active connections to die. I am wondering why not we >> call CountOtherDBBackends from TerminateOtherDBBackends after sending >> the SIGTERM to all the sessions that are connected to the database >> being dropped? Currently, it looks odd that first, we wait for 100ms >> after sending the signal and then separately wait for 5s in another >> function. > > > I'll look to this part, but I don't think so it is bad. 5s is maximum, not > minimum of waiting. So if sigterm is successful in first 100ms, then > CountOtherDBBackends doesn't add any time. If not, then it dynamically > waiting. > > If we don't wait in TerminateOtherDBBackends, then probably there should be > necessary some cycles inside CountOtherDBBackends. I think so code like is > correct > > 1. send SIGTERM to target processes > 2. put some time to processes for logout (100ms) > 3. check in loop (max 5 sec) on logout of all processes > > Maybe my feeling is wrong, but I think so it is good to wait few time instead > to call CountOtherDBBackends immediately - the first iteration should to > fail, and then first iteration is useless without chance on success. >
I think the way I am suggesting by skipping the second step will allow sleeping only when required. Consider a case where there are just one or two sessions connected to the database and they immediately exited after the signal is sent. In such a case you don't need to sleep at all whereas, under your proposal, it will always sleep. In the case where a large number of sessions are present and the first 100ms are not sufficient, we anyway need to wait dynamically. So, I think the second step not only looks odd but also seems to be redundant. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
