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.
