Re: dropdb --force

On Wed, Nov 6, 2019 at 11:46 PM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>
> 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.
>>

Right, this makes sense. I think I was overly paranoid about this
behavior even though that was used at a few other places as this patch
might need to rely on many pids not being reused after the lock is
released.

>
>
> so we can return back to just simple killing.
>

I think so. I think we might want to add a comment about this race
condition and add or reference to comments in pg_signal_backend which
mentions the same race condition.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com