Re: dropdb --force

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.