Re: Race-like failure in recovery/t/009_twophase.pl
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2017-07-03T01:23:59Z
Lists: pgsql-hackers
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
Commits
-
Fix race condition in recovery/t/009_twophase.pl test.
- 647675228f2b 10.0 landed
-
Fix bug in PostgresNode::query_hash's split() call.
- efdb4f29ba9e 10.0 landed
-
Try to improve readability of recovery/t/009_twophase.pl test.
- 4e15387d2d9d 10.0 landed