Re: dropdb --force
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, vignesh C <vignesh21@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Ryan Lambert <ryan@rustprooflabs.com>, 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-11-07T05:58:35Z
Lists: pgsql-hackers
čt 7. 11. 2019 v 6:56 odesílatel Amit Kapila <amit.kapila16@gmail.com> napsal: > On Thu, Nov 7, 2019 at 10:46 AM Pavel Stehule <pavel.stehule@gmail.com> > wrote: > > > > čt 7. 11. 2019 v 3:42 odesílatel Amit Kapila <amit.kapila16@gmail.com> > napsal: > >> > >> On Wed, Nov 6, 2019 at 11:46 PM Pavel Stehule <pavel.stehule@gmail.com> > wrote: > >> > > >> > st 6. 11. 2019 v 14:59 odesílatel Tom Lane <tgl@sss.pgh.pa.us> > napsal: > >> >> > >> >> Amit Kapila <amit.kapila16@gmail.com> writes: > >> >> > I think there is still a window where the same problem can happen, > say > >> >> > the signal has been sent by SendProcSignal to the required process > and > >> >> > it releases the ProcArrayLock. Now, the target process exits and a > >> >> > new process gets the same pid before the signal is received. > >> >> > >> >> In principle, no use of Unix signals is ever safe against this sort > >> >> of race condition --- process A can never know that process B didn't > >> >> exit immediately before A does kill(B, n). In practice, it's okay > >> >> because the kernel is expected not to reassign a dead PID for some > >> >> reasonable grace period [1]. I'd be inclined to lean more heavily > >> >> on that expectation than anything internal to Postgres. That is, > >> >> remembering the PID we want to kill for some small number of > >> >> microseconds is probably a safer API than anything that depends on > >> >> the contents of the ProcArray, because there indeed *isn't* any > >> >> guarantee that a ProcArray entry won't be recycled immediately. > >> >> > >> > >> Right, this makes sense. I think I was overly paranoid about this > >> behavior even though that was used at a few other places as this patch > >> might need to rely on many pids not being reused after the lock is > >> released. > >> > >> > > >> > > >> > so we can return back to just simple killing. > >> > > >> > >> I think so. I think we might want to add a comment about this race > >> condition and add or reference to comments in pg_signal_backend which > >> mentions the same race condition. > > > > > > Please, can you do it. It's bad task for my with my bad English. > > > > Okay, no problem. I will pick the previous version and do this. I > will post the patch in a day or so for your review. > Thank you very much Pavel > > -- > 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