Re: Handle infinite recursion in logical replication setup

vignesh C <vignesh21@gmail.com>

From: vignesh C <vignesh21@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: "shiy.fnst@fujitsu.com" <shiy.fnst@fujitsu.com>, Peter Smith <smithpb2250@gmail.com>, "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>, Dilip Kumar <dilipbalaut@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, "kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>, "Jonathan S. Katz" <jkatz@postgresql.org>
Date: 2022-09-08T04:01:50Z
Lists: pgsql-hackers

Attachments

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

Commits

  1. Improved CREATE SUBSCRIPTION message for clarity

  2. Fix the test case introduced by commit 8756930190.

  3. Raise a warning if there is a possibility of data from multiple origins.

  4. Add wait_for_subscription_sync for TAP tests.

  5. Bump catversion for commit d8cd0c6c95c0120168df93aae095df4e0682a08a.

  6. Allow users to skip logical replication of data having origin.

  7. Improve two comments related to a boolean DefElem's value

  8. doc: Fix man page whitespace issues