Fix another instability in recovery TAP test 004_timeline_switch

The test did not wait for the standby to be connected to the primary.
This breaks one assumption at the beginning of the test, where the
primary is stopped to ensure that all its records are flushed to both
standbys before moving on with its next steps.

If standby_1 finishes ahead of standby_2, the test would be able work
fine as the former waits for the latter.  The opposite is not true,
standby_2 getting ahead of standby_1 would cause the test to fail on
timeout when standby_1 attempts to connect to standby_2.

This commit adds an additional polling query after the two standbys are
started, checking that both standbys are connected to the primary before
processing with the initial steps of the test.

Like 7185eddf0522, backpatch down to v14.

Author: Sergey Tatarintsev <s.tatarintsev@postgrespro.ru>
Reviewed-by: Ewan Young <kdbase.hack@gmail.com>
Discussion: https://postgr.es/m/fea4190e-f8b5-4432-a52d-bcbee5f34366@postgrespro.ru
Backpatch-through: 14

diff --git a/src/test/recovery/t/004_timeline_switch.pl b/src/test/recovery/t/004_timeline_switch.pl
index bf9a92cb34c8b75c3f7c638f03bf1620360823ff..2f2e80108640d155ee32ce58185b2f9efcc67040 100644 (file)
--- a/src/test/recovery/t/004_timeline_switch.pl
+++ b/src/test/recovery/t/004_timeline_switch.pl
@@ -33,6 +33,10 @@ $node_standby_2->init_from_backup($node_primary, $backup_name,
        has_streaming => 1);
 $node_standby_2->start;
 
+# Wait for standby_1 and standby_2 connection to the primary.
+$node_primary->poll_query_until('postgres',
+       "SELECT count(1) = 2 FROM pg_stat_replication");
+
 # Create some content on primary
 $node_primary->safe_psql('postgres',
        "CREATE TABLE tab_int AS SELECT generate_series(1,1000) AS a");