Re: dropdb --force - Mailing list pgsql-hackers
| From | Pavel Stehule |
|---|---|
| Subject | Re: dropdb --force |
| Date | |
| Msg-id | CAFj8pRB952L22o8+Em23u-vz1n2PmyfybcAuUa8FqBcUEbz2vg@mail.gmail.com Whole thread Raw |
| In response to | Re: dropdb --force (Amit Kapila <amit.kapila16@gmail.com>) |
| Responses |
Re: dropdb --force
|
| List | pgsql-hackers |
po 21. 10. 2019 v 10:25 odesílatel Amit Kapila <amit.kapila16@gmail.com> napsal:
On Mon, Oct 21, 2019 at 12:24 PM Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
> po 21. 10. 2019 v 8:38 odesílatel Amit Kapila <amit.kapila16@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
pgsql-hackers by date: