From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael.paquier@gmail.com>
cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Subject: Re: Race-like failure in recovery/t/009_twophase.pl
In-reply-to: 
 <CAB7nPqSOFT7Tg8Qk+tkzXZezWPbcc4THr924mHb1+PMN55RbxA@mail.gmail.com>
References: <908.1498965681@sss.pgh.pa.us> <31663.1499032944@sss.pgh.pa.us>
 <CAB7nPqSOFT7Tg8Qk+tkzXZezWPbcc4THr924mHb1+PMN55RbxA@mail.gmail.com>
Comments: In-reply-to Michael Paquier <michael.paquier@gmail.com>
	message dated "Mon, 03 Jul 2017 10:15:15 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <15458.1499045039.1@sss.pgh.pa.us>
Date: Sun, 02 Jul 2017 21:23:59 -0400
Message-ID: <15459.1499045039@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Michael Paquier <michael.paquier@gmail.com> writes:
> On Mon, Jul 3, 2017 at 7:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Anyone have a different view of what to fix here?

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

Oh, that's a good way.  I just finished testing a fix that involved
not turning on the second server's sync commit until later (it seems
that only the first action on "paris" is really at risk currently).
But disabling sync commit for individual transactions is clearly cleaner
and more extensible to future test script changes.

FWIW, I just got done doing a few check-world cycles with the delay in
WalReceiverMain plus speeding up pg_ctl.c to WAITS_PER_SEC = 1000.
No other problems seem to be revealed this way.

			regards, tom lane


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