Re: Handle infinite recursion in logical replication setup

From: vignesh C <vignesh21(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: "shiy(dot)fnst(at)fujitsu(dot)com" <shiy(dot)fnst(at)fujitsu(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
Subject: Re: Handle infinite recursion in logical replication setup
Date: 2022-09-08 04:01:50
Message-ID: CALDaNm1W35=dAy3XVFTcvQ_papdgXw2VJTNTfv2ivz_BjHJALg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 8 Sept 2022 at 08:57, vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Thu, 8 Sept 2022 at 08:23, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Thu, Sep 8, 2022 at 7:57 AM vignesh C <vignesh21(at)gmail(dot)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

Attachment Content-Type Size
0001-Fix-buildfarm-tap-test-failure.patch application/octet-stream 1.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2022-09-08 04:40:20 Re: more descriptive message for process termination due to max_slot_wal_keep_size
Previous Message vignesh C 2022-09-08 03:27:00 Re: Handle infinite recursion in logical replication setup