And *another* replication test race condition just now:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dangomushi&dt=2017-08-26%2019%3A37%3A08
As best I can interpret this, it's pointing out that this bit in
src/test/recovery/t/009_twophase.pl:
$cur_master->psql('postgres', "BEGIN;CREATE TABLE t_009_tbl2 (id int, msg text);SAVEPOINT s1;INSERT INTO t_009_tbl2
VALUES(27, 'issued to ${cur_master_name}');PREPARE TRANSACTION 'xact_009_13';-- checkpoint will issue XLOG_STANDBY_LOCK
thatcan conflict with lock-- held by 'create table' statementCHECKPOINT;COMMIT PREPARED 'xact_009_13';");
$cur_standby->psql('postgres',"SELECT count(*) FROM t_009_tbl2",stdout => \$psql_out);
is($psql_out, '1', "Replay prepared transaction with DDL");
contains exactly no means of ensuring that the master's transaction has
been replayed on the standby before we check for its results. It's not
real clear why it seems to work 99.99% of the time, because, well, there
isn't any frickin' interlock there ...
regards, tom lane
