Re: dropdb --force

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