Re: dropdb --force

st 6. 11. 2019 v 14:59 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Amit Kapila <amit(dot)kapila16(at)gmail(dot)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