Re: [HACKERS] Race-like failure in recovery/t/009_twophase.pl - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] Race-like failure in recovery/t/009_twophase.pl
Date
Msg-id CAB7nPqSOFT7Tg8Qk+tkzXZezWPbcc4THr924mHb1+PMN55RbxA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Race-like failure in recovery/t/009_twophase.pl  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Race-like failure in recovery/t/009_twophase.pl
List pgsql-hackers
(catching up test threads)

On Mon, Jul 3, 2017 at 7:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I'm now inclined to think that the correct fix is to ensure that we
> run synchronous rep in both directions, rather than to insert delays
> to substitute for that.  Just setting synchronous_standby_names for
> node paris at the top of the script doesn't work, because there's
> at least one place where the script intentionally issues commands
> to paris while london is stopped.

I bet that using syncrep in both directions will likely avoid
inconsistencies in the future if the test suite is extended on way or
another.

> But we could turn off sync rep for that step, perhaps.

Yeah, by using synchronous_commit = off.

> Anyone have a different view of what to fix here?

No, this sounds like a good plan. What do you think about the attached?
-- 
Michael

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] PostgresNode::poll_query_until hacking
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Race-like failure in recovery/t/009_twophase.pl