On Mon, 19 Feb 2024 at 12:38, Amit Kapila <amit.kapil...@gmail.com> wrote:
>
> On Mon, Feb 19, 2024 at 6:54 AM Hayato Kuroda (Fujitsu)
> <kuroda.hay...@fujitsu.com> wrote:
> >
> > Thanks for reviewing! PSA new version.
> >
>
> Pushed this after making minor changes in the comments.

Recently there was a failure in 004_subscription tap test at [1].
In this failure, the tab_upgraded1 table was expected to have 51
records but has only 50 records. Before the upgrade both publisher and
subscriber have 50 records.
After the upgrade we have inserted one record in the publisher, now
tab_upgraded1 will have 51 records in the publisher. Then we start the
subscriber after changing max_logical_replication_workers so that
apply workers get started and apply the changes received. After
starting we enable regress_sub5, wait for sync of regress_sub5
subscription and check for tab_upgraded1 and tab_upgraded2 table data.
In a few random cases the one record that was inserted into
tab_upgraded1 table will not get replicated as we have not waited for
regress_sub4 subscription to apply the changes from the publisher.
The attached patch has changes to wait for regress_sub4 subscription
to apply the changes from the publisher before verifying the data.

[1] - 
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mamba&dt=2024-03-26%2004%3A23%3A13

Regards,
Vignesh
From 69d7adc27198d5cf3ecf5b8c7d62a3e41263bc2a Mon Sep 17 00:00:00 2001
From: Vignesh C <vignes...@gmail.com>
Date: Wed, 27 Mar 2024 11:27:34 +0530
Subject: [PATCH v1] Fix random upgrade failure test in 004_subscription tap
 test.

The test was failing because the incremental changes had not been replicated to
the subscriber after subscriber was started. The changes were not
replicated as we were checking the table data immediately after the
server was started. This test did not wait for regress_sub4 subscription to
apply the changes for tab_upgraded1 table. Fixed it by waiting until the
subscription was synced to get all the changes for tab_upgraded1 table data.
---
 src/bin/pg_upgrade/t/004_subscription.pl | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/bin/pg_upgrade/t/004_subscription.pl b/src/bin/pg_upgrade/t/004_subscription.pl
index df5d6dffbc..06504e70c1 100644
--- a/src/bin/pg_upgrade/t/004_subscription.pl
+++ b/src/bin/pg_upgrade/t/004_subscription.pl
@@ -306,12 +306,14 @@ $result = $new_sub->safe_psql('postgres',
 );
 is($result, qq($remote_lsn), "remote_lsn should have been preserved");
 
-# Resume the initial sync and wait until all tables of subscription
-# 'regress_sub5' are synchronized
+# Resume the initial sync
 $new_sub->append_conf('postgresql.conf',
 	"max_logical_replication_workers = 10");
 $new_sub->restart;
 $new_sub->safe_psql('postgres', "ALTER SUBSCRIPTION regress_sub5 ENABLE");
+
+# Wait until both subscriptions catch up the changes on the publisher
+$publisher->wait_for_catchup('regress_sub4');
 $new_sub->wait_for_subscription_sync($publisher, 'regress_sub5');
 
 # Rows on tab_upgraded1 and tab_upgraded2 should have been replicated
-- 
2.34.1

Reply via email to