Dear Vignesh, > > 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.
Good catch! > 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 Yeah, I think it is an oversight in f17529. Previously subscriptions which receiving changes were confirmed to be caught up, I missed to add the line while restructuring the script. +1 for your fix. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/