Re: dropdb --force

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, vignesh C <vignesh21(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Ryan Lambert <ryan(at)rustprooflabs(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Anthony Nowocien <anowocien(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Filip Rembiałkowski <filip(dot)rembialkowski(at)gmail(dot)com>
Subject: Re: dropdb --force
Date: 2019-11-07 05:58:35
Message-ID: CAFj8pRDZK2zdDgL7b3DS4YEFnfaxcMf7PON1eB1wsor2MauJSA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

> On Thu, Nov 7, 2019 at 10:46 AM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> >
> > č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.
> >
>
> Okay, no problem. I will pick the previous version and do this. I
> will post the patch in a day or so for your review.
>

Thank you very much

Pavel

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2019-11-07 06:09:44 Re: Keep compiler silence (clang 10, implicit conversion from 'long' to 'double' )
Previous Message Amit Kapila 2019-11-07 05:56:21 Re: dropdb --force