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.
