Re: dropdb --force

po 21. 10. 2019 v 8:38 odesílatel Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
napsal:

> On Mon, Oct 21, 2019 at 11:08 AM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> >
> > po 21. 10. 2019 v 7:11 odesílatel Amit Kapila <amit(dot)kapila16(at)gmail(dot)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
>