Re: YA race condition in 001_stream_rep.pl (was Re: pgsql: Allow using the updated tuple while moving it to a different par)

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: YA race condition in 001_stream_rep.pl (was Re: pgsql: Allow using the updated tuple while moving it to a different par)
Date: 2018-07-15 11:09:50
Message-ID: CAA4eK1LHrn2TNXUU7n-uMENBxkgepe15DG8+eGehG+eWVKF7ag@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Sat, Jul 14, 2018 at 11:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Michael Paquier 2018-07-16 02:10:36 Refactor documentation for wait events (Was: pgsql: Add wait event for fsync of WAL segments)
Previous Message Alvaro Herrera 2018-07-15 00:11:38 Re: pgsql: Fix FK checks of TRUNCATE involving partitioned tables

Browse pgsql-hackers by date

  From Date Subject
Next Message Vik Fearing 2018-07-15 11:10:54 Re: Allow to specify a index name as ANALYZE parameter
Previous Message Vik Fearing 2018-07-15 10:53:29 Re: New GUC to sample log queries