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