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-21T08:25:09Z
Lists: pgsql-hackers
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? > 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
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