Re: dropdb --force

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Ryan Lambert <ryan(at)rustprooflabs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Anthony Nowocien <anowocien(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Filip Rembiałkowski <filip(dot)rembialkowski(at)gmail(dot)com>
Subject: Re: dropdb --force
Date: 2019-10-21 08:44:43
Message-ID: CAFj8pRB952L22o8+Em23u-vz1n2PmyfybcAuUa8FqBcUEbz2vg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

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

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
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Borodin 2019-10-21 09:00:47 Re: Questions/Observations related to Gist vacuum
Previous Message Etsuro Fujita 2019-10-21 08:44:25 Re: Obsolete comment in partbounds.c