On Thu, 8 Sept 2022 at 08:57, vignesh C <vignes...@gmail.com> wrote: > > On Thu, 8 Sept 2022 at 08:23, Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Thu, Sep 8, 2022 at 7:57 AM vignesh C <vignes...@gmail.com> wrote: > > > > > > There is a buildfarm failure on mylodon at [1] because of the new test > > > added. I will analyse and share the findings for the same. > > > > > > [1] - > > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mylodon&dt=2022-09-08%2001%3A40%3A27 > > > > > > > The log is as below: > > > > error running SQL: 'psql:<stdin>:1: ERROR: could not drop relation > > mapping for subscription "tap_sub_a_b_2" > > DETAIL: Table synchronization for relation "tab_new" is in progress > > and is in state "s". > > HINT: Use ALTER SUBSCRIPTION ... ENABLE to enable subscription if not > > already enabled or use DROP SUBSCRIPTION ... to drop the > > subscription.' > > while running 'psql -XAtq -d port=50352 host=/tmp/WMoRd6ngw2 > > dbname='postgres' -f - -v ON_ERROR_STOP=1' with sql 'DROP TABLE > > tab_new' at > > /mnt/resource/bf/build/mylodon/HEAD/pgsql.build/../pgsql/src/test/perl/PostgreSQL/Test/Cluster.pm > > line 1860. > > ### Stopping node "node_A" using mode immediate > > > > This clearly indicates the problem. We can't drop the relation till it > > is marked ready in pg_subscription_rel and prior to dropping, the test > > just does $node_A->wait_for_subscription_sync($node_B, $subname_AB2);. > > This doesn't ensure that relation is in 'ready' state as it will > > finish even when the relation is in 'syncdone' state. > > I agree with the analysis, adding wait for ready state before dropping > the table approach looks good to me. I will prepare a patch for the > same and share it.
The attached patch has the changes to handle the same. Regards, Vignesh
0001-Fix-buildfarm-tap-test-failure.patch
Description: Binary data