Re: dropdb --force
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Ryan Lambert <ryan@rustprooflabs.com>, Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@gmail.com>, Anthony Nowocien <anowocien@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Filip Rembiałkowski <filip.rembialkowski@gmail.com>
Date: 2019-10-22T03:09:40Z
Lists: pgsql-hackers
On Mon, Oct 21, 2019 at 2:15 PM Pavel Stehule <pavel.stehule@gmail.com> wrote: > > po 21. 10. 2019 v 10:25 odesílatel Amit Kapila <amit.kapila16@gmail.com> napsal: >> >> >> 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. > Hmm, can't we pass force as a parameter to TerminateOtherDBBackends() and then take the decision inside that function? That will make the code of dropdb function a bit simpler. > 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? > CountOtherDBBackends is called from other places as well, so I don't think it is advisable to change the sleep time in that function. Also, I don't want to add a parameter for it. I think you have a point that in some cases we might end up sleeping for 100ms when we could do with less sleeping time, but I think it is true to some extent today as well. I think we can anyway change it in the future if there is a problem with the sleep timing, but for now, I think we can just call CountOtherDBBackends after sending SIGTERM and call it good. You might want to add a futuristic note in the code. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Commits
-
Add tests for '-f' option in dropdb utility.
- 8a7e9e9dad56 13.0 landed
-
Move pump_until to TestLib.pm.
- 290acac92b1d 13.0 landed
-
Add the support for '-f' option in dropdb utility.
- 80e05a088e4e 13.0 landed
-
Introduce the 'force' option for the Drop Database command.
- 1379fd537f9f 13.0 landed
-
Improve CREATE/DROP/RENAME DATABASE so that when failing because the source
- 4abd7b49f1e9 8.4.0 cited