Re: YA race condition in 001_stream_rep.pl (was Re: pgsql: Allowusing the updated tuple while moving it to a different par) - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: YA race condition in 001_stream_rep.pl (was Re: pgsql: Allowusing the updated tuple while moving it to a different par)
Date
Msg-id CAA4eK1LHrn2TNXUU7n-uMENBxkgepe15DG8+eGehG+eWVKF7ag@mail.gmail.com
Whole thread Raw
In response to YA race condition in 001_stream_rep.pl (was Re: pgsql: Allow using the updated tuple while moving it to a different par)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: YA race condition in 001_stream_rep.pl (was Re: pgsql: Allow using the updated tuple while moving it to a different par)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Jul 14, 2018 at 11:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>
> I can reproduce the failure pretty reliably with a hack like the one
> attached, which makes it unlikely that the walreceiver will send a
> feedback message instantly when it gets the SIGHUP.
>
> So the issue boils down to this: the test script is, effectively,
> assuming that it's guaranteed that the walreceiver will send a feedback
> message before it shuts down; but there is no such guarantee.  Is this
> a bug in the test script, or a bug in the walreceiver logic?  I can
> see the value of having such a guarantee, but I also think it would be
> nigh impossible to make it a bulletproof guarantee.  We could perhaps
> add "XLogWalRcvSendHSFeedback(true)" somewhere closer to process exit,
> but that might add more failure modes than it removes.
>
> Or we could change the test script to wait for feedback before it
> issues the shutdown, but then I think the test is a bit pointless.
>

Currently, neither the code nor our documentation suggests that we can
expect HSFeedback before the shutdown, so it is better to adjust the
test.  If the sole purpose of the test is to test feedback after
shutdown, then it is worth considering to remove the test altogether.

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


pgsql-hackers by date:

Previous
From: Vik Fearing
Date:
Subject: Re: New GUC to sample log queries
Next
From: Vik Fearing
Date:
Subject: Re: Allow to specify a index name as ANALYZE parameter