Fix random failure in 004_subscription.

After the upgrade, the failed test was ensuring that the changes made on
the publisher should be replicated to the subscriber. We missed waiting
for one of the subscriptions to catch up.

Per buildfarm

Author: Vignesh C
Reviewed-by: Kuroda Hayato
Discussion: https://postgr.es/m/CALDaNm0z=fLtio1h50K8WossUGXU+gy0H9y9=RYh1DDZiq2EDw@mail.gmail.com

diff --git a/src/bin/pg_upgrade/t/004_subscription.pl b/src/bin/pg_upgrade/t/004_subscription.pl
index df5d6dffbc309f846954bb71c38dbcbbbb0bd2e5..48918e8c294ec1c303afec76a731adecaf164eab 100644 (file)
--- a/src/bin/pg_upgrade/t/004_subscription.pl
+++ b/src/bin/pg_upgrade/t/004_subscription.pl
@@ -314,6 +314,9 @@ $new_sub->restart;
 $new_sub->safe_psql('postgres', "ALTER SUBSCRIPTION regress_sub5 ENABLE");
 $new_sub->wait_for_subscription_sync($publisher, 'regress_sub5');
 
+# wait for regress_sub4 to catchup as well
+$publisher->wait_for_catchup('regress_sub4');
+
 # Rows on tab_upgraded1 and tab_upgraded2 should have been replicated
 $result =
   $new_sub->safe_psql('postgres', "SELECT count(*) FROM tab_upgraded1");