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.
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.
