Re: dropdb --force

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

> 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?

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