st 6. 11. 2019 v 14:59 odesÃlatel Tom Lane <t...@sss.pgh.pa.us> napsal:
> Amit Kapila <amit.kapil...@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. > > regards, tom lane > > [1] and also because the kernel *can't* recycle the PID until the > parent process has reaped the zombie process-table entry. Thus, > for example, it's unconditionally safe for the postmaster to signal > its children, because those PIDs can't move until the postmaster > accepts the SIGCHLD signal and does a wait() for them. Any > interprocess signals between child processes are inherently a tad > less safe. But we've gotten away with interprocess SIGUSR1 for > decades with no reported problems. I don't really think that we > need to move the goalposts for SIGINT, and I'm entirely not in > favor of the sorts of complications that are being proposed here. > so we can return back to just simple killing. Regards Pavel
