Skip to content

Commit 46fb7ff

Browse files
committed
Improve stability of TAP test for synchronous replication
Slow buildfarm machines have run into issues with this TAP test caused by a race condition related to the startup of a set of standbys, where it is possible to finish with an unexpected order in the WAL sender array of the primary. This closes the race condition by making sure that any standby started is registered into the WAL sender array of the primary before starting the next one based on lookups of pg_stat_replication. Backpatch down to 9.6 where the test has been introduced. Author: Michael Paquier Reviewed-by: Álvaro Herrera, Noah Misch Discussion: https://postgr.es/m/20190617055145.GB18917@paquier.xyz Backpatch-through: 9.6
1 parent 7ac7bf5 commit 46fb7ff

File tree

1 file changed

+33
-9
lines changed

1 file changed

+33
-9
lines changed

src/test/recovery/t/007_sync_rep.pl

Lines changed: 33 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -26,6 +26,23 @@ sub test_sync_state
2626
ok($self->poll_query_until('postgres', $check_sql, $expected), $msg);
2727
}
2828

29+
# Start a standby and check that it is registered within the WAL sender
30+
# array of the given primary. This polls the primary's pg_stat_replication
31+
# until the standby is confirmed as registered.
32+
sub start_standby_and_wait
33+
{
34+
my ($master, $standby) = @_;
35+
my $master_name = $master->name;
36+
my $standby_name = $standby->name;
37+
my $query =
38+
"SELECT count(1) = 1 FROM pg_stat_replication WHERE application_name = '$standby_name'";
39+
40+
$standby->start;
41+
42+
print("### Waiting for standby \"$standby_name\" on \"$master_name\"\n");
43+
$master->poll_query_until('postgres', $query);
44+
}
45+
2946
# Initialize master node
3047
my $node_master = get_new_node('master');
3148
$node_master->init(allows_streaming => 1);
@@ -35,23 +52,26 @@ sub test_sync_state
3552
# Take backup
3653
$node_master->backup($backup_name);
3754

55+
# Create all the standbys. Their status on the primary is checked to ensure
56+
# the ordering of each one of them in the WAL sender array of the primary.
57+
3858
# Create standby1 linking to master
3959
my $node_standby_1 = get_new_node('standby1');
4060
$node_standby_1->init_from_backup($node_master, $backup_name,
4161
has_streaming => 1);
42-
$node_standby_1->start;
62+
start_standby_and_wait($node_master, $node_standby_1);
4363

4464
# Create standby2 linking to master
4565
my $node_standby_2 = get_new_node('standby2');
4666
$node_standby_2->init_from_backup($node_master, $backup_name,
4767
has_streaming => 1);
48-
$node_standby_2->start;
68+
start_standby_and_wait($node_master, $node_standby_2);
4969

5070
# Create standby3 linking to master
5171
my $node_standby_3 = get_new_node('standby3');
5272
$node_standby_3->init_from_backup($node_master, $backup_name,
5373
has_streaming => 1);
54-
$node_standby_3->start;
74+
start_standby_and_wait($node_master, $node_standby_3);
5575

5676
# Check that sync_state is determined correctly when
5777
# synchronous_standby_names is specified in old syntax.
@@ -81,8 +101,10 @@ sub test_sync_state
81101
$node_standby_2->stop;
82102
$node_standby_3->stop;
83103

84-
$node_standby_2->start;
85-
$node_standby_3->start;
104+
# Make sure that each standby reports back to the primary in the wanted
105+
# order.
106+
start_standby_and_wait($node_master, $node_standby_2);
107+
start_standby_and_wait($node_master, $node_standby_3);
86108

87109
# Specify 2 as the number of sync standbys.
88110
# Check that two standbys are in 'sync' state.
@@ -93,7 +115,7 @@ sub test_sync_state
93115
'2(standby1,standby2,standby3)');
94116

95117
# Start standby1
96-
$node_standby_1->start;
118+
start_standby_and_wait($node_master, $node_standby_1);
97119

98120
# Create standby4 linking to master
99121
my $node_standby_4 = get_new_node('standby4');
@@ -125,14 +147,16 @@ sub test_sync_state
125147

126148
# The setting that * comes before another standby name is acceptable
127149
# but does not make sense in most cases. Check that sync_state is
128-
# chosen properly even in case of that setting.
129-
# The priority of standby2 should be 2 because it matches * first.
150+
# chosen properly even in case of that setting. standby1 is selected
151+
# as synchronous as it has the highest priority, and is followed by a
152+
# second standby listed first in the WAL sender array, which is
153+
# standby2 in this case.
130154
test_sync_state(
131155
$node_master, qq(standby1|1|sync
132156
standby2|2|sync
133157
standby3|2|potential
134158
standby4|2|potential),
135-
'asterisk comes before another standby name',
159+
'asterisk before another standby name',
136160
'2(standby1,*,standby2)');
137161

138162
# Check that the setting of '2(*)' chooses standby2 and standby3 that are stored

0 commit comments

Comments
 (0)