po 21. 10. 2019 v 10:25 odesílatel Amit Kapila <amit.kapil...@gmail.com>
napsal:

> On Mon, Oct 21, 2019 at 12:24 PM Pavel Stehule <pavel.steh...@gmail.com>
> wrote:
> >
> > po 21. 10. 2019 v 8:38 odesílatel Amit Kapila <amit.kapil...@gmail.com>
> napsal:
> >>
> >> > 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.
> >
>
> Sorry, but I am not able to understand the reason.  Are you worried
> about the comments atop CountOtherDBBackends which says it is used in
> Drop Database and related commands?
>

no, just now the code in dropdb looks like

if (force)
    TerminateOtherDBBackends(...);

CountOtherDBBackends(...);

if I call CountOtherDBBackends from TerminateOtherDBBackends, then code
will look like

if (force)
  TerminateOtherDBBackends(...);
else
  CountOtherDBBackends(...);

That looks like CountOtherDBBackends is not called when force clause is
active. And this is not true.

So I prefer current relations between routines.




> > 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?
> >
>
> I am not completely sure about what is the most appropriate thing to
> do, but I favor removing sleep from TerminateOtherDBBackends.  OTOH,
> there is nothing broken with the logic.  Anyone else wants to weigh in
> here?
>

ok. But when I remove it, should not be better to set waiting in
CountOtherDBBackends to some smaller number than 100ms?

Pavel

>
>
>
> --
> With Regards,
> Amit Kapila.
> EnterpriseDB: http://www.enterprisedb.com
>

Reply via email to