po 21. 10. 2019 v 8:38 odesÃlatel Amit Kapila <amit.kapil...@gmail.com> napsal:
> 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. > I checked the code, and I think so calling CountOtherDBBackends from TerminateOtherDBBackends is not good idea. CountOtherDBBackends should be called anywhere, TerminateOtherDBBackends only with FORCE flag. So I wouldn't to change code. But I can (and I have not any problem with it) remove or significantly decrease sleeping time in TerminateOtherDBBackends. 100 ms is maybe very much - but zero is maybe too low. If there will not be any time between TerminateOtherDBBackends and CountOtherDBBackends, then probably CountOtherDBBackends hit waiting 100ms. What about only 5 ms sleeping in TerminateOtherDBBackends? > -- > With Regards, > Amit Kapila. > EnterpriseDB: http://www.enterprisedb.com >
