Re: dropdb --force - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: dropdb --force
Date
Msg-id CAFj8pRDZK2zdDgL7b3DS4YEFnfaxcMf7PON1eB1wsor2MauJSA@mail.gmail.com
Whole thread Raw
In response to Re: dropdb --force  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: dropdb --force  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers


čt 7. 11. 2019 v 6:56 odesílatel Amit Kapila <amit.kapila16@gmail.com> napsal:
On Thu, Nov 7, 2019 at 10:46 AM Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
> čt 7. 11. 2019 v 3:42 odesílatel Amit Kapila <amit.kapila16@gmail.com> napsal:
>>
>> On Wed, Nov 6, 2019 at 11:46 PM Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> >
>> > st 6. 11. 2019 v 14:59 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
>> >>
>> >> 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.
>> >>
>>
>> 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

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: dropdb --force
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Keep compiler silence (clang 10, implicit conversion from'long' to 'double' )