Re: dropdb --force

čt 7. 11. 2019 v 3:42 odesílatel Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
napsal:

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

Please, can you do it. It's bad task for my with my bad English.

Thank you

Pavel

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