Re: [BUG] wrong refresh when ALTER SUBSCRIPTION ADD/DROP PUBLICATION - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: [BUG] wrong refresh when ALTER SUBSCRIPTION ADD/DROP PUBLICATION
Date
Msg-id CAD21AoABYbpnXFNMuFmogx9jMrV3u=4NOQzqosvMoG9Op8nfdg@mail.gmail.com
Whole thread Raw
In response to Re: [BUG] wrong refresh when ALTER SUBSCRIPTION ADD/DROP PUBLICATION  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Thu, Aug 5, 2021 at 2:08 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Wed, Aug 4, 2021 at 9:19 PM houzj.fnst@fujitsu.com
> <houzj.fnst@fujitsu.com> wrote:
> >
> > On Wednesday, August 4, 2021 7:00 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote
> > > On Wed, Aug 4, 2021 at 5:06 PM houzj.fnst@fujitsu.com <houzj.fnst@fujitsu.com> wrote:
> > > >
> > > > On Wednesday, August 4, 2021 1:47 PM Masahiko Sawada <sawada.mshk@gmail.com>
> > > > >
> > > > > I've not looked at the patch deeply yet but I think that the
> > > > > following one line change seems to fix the cases you reported,
> > > > > although I migit be missing
> > > > > something:
> > > > >
> > > > > diff --git a/src/backend/commands/subscriptioncmds.c
> > > > > b/src/backend/commands/subscriptioncmds.c
> > > > > index 22ae982328..c74d6d51d6 100644
> > > > > --- a/src/backend/commands/subscriptioncmds.c
> > > > > +++ b/src/backend/commands/subscriptioncmds.c
> > > > > @@ -1068,7 +1068,7 @@ AlterSubscription(ParseState *pstate,
> > > > > AlterSubscriptionStmt *stmt,
> > > > >                     PreventInTransactionBlock(isTopLevel, "ALTER
> > > > > SUBSCRIPTION with refresh");
> > > > >
> > > > >                     /* Only refresh the added/dropped list of publications.
> > > */
> > > > > -                   sub->publications = stmt->publication;
> > > > > +                   sub->publications = publist;
> > > > >
> > > > >                     AlterSubscription_refresh(sub, opts.copy_data);
> > > > >                 }
> > > >
> > > > I considered the same fix before, but with the above fix, it seems
> > > > refresh both existsing publications and new publication, which most of
> > > > people didn't like in previous discussion[1]. From the doc[2], IIRC,
> > > > Currently, the ADD/DROP PUBLICATION is supposed to only refresh the new
> > > publication.
> > >
> > > What do you mean by refreshing both existing and new publications? I dropped
> > > and created one publication out of three publications that the subscription is
> > > subscribing to but the corresponding entries in pg_subscription_rel for tables
> > > associated with the other two publications were not changed and the table sync
> > > workers also were not started for them.
> > >
> >
> > +                   sub->publications = publist;
> > -                   sub->publications = stmt->publication;
> > With the above fix, When ADD/DROP PUBLICATION, I meant the table that doesn't
> > belong to the dropped or added publication could be updated in
> > pg_subscription_rel.
> >
> > I can see the effect in the following example:
> >
> > 1)-publisher-
> > CREATE TABLE test,test2,test3
> > CREATE PUBLICATION pub FOR TABLE test;
> > CREATE PUBLICATION pub2 FOR TABLE test2;
> > 2)-subscriber-
> > CREATE TABLE test,test2,test3
> > CREATE SUBSCRIPTION sub CONNECTION 'dbname=postgres port=10000' PUBLICATION pub,pub2;
> > select * from pg_subscription_rel;
> > -[ RECORD 1 ]---------
> > srsubid    | 16393
> > srrelid    | 16387
> > srsubstate | r
> > srsublsn   | 0/150A2D8
> > -[ RECORD 2 ]---------
> > srsubid    | 16393
> > srrelid    | 16384
> > srsubstate | r
> > srsublsn   | 0/150A310
> >
> > 3)-publisher-
> > alter publication pub add table test3;
> > 4)-subscriber-
> > ALTER SUBSCRIPTION sub drop PUBLICATION pub2;
> > select * from pg_subscription_rel;
> > -[ RECORD 1 ]---------
> > srsubid    | 16393
> > srrelid    | 16384
> > srsubstate | r
> > srsublsn   | 0/150A310
> > -[ RECORD 2 ]---------
> > srsubid    | 16393
> > srrelid    | 16390
> > srsubstate | r
> > srsublsn   |
> >
> > I can see the [RECORD 2] which is the new registered table in 'pub2' (see step 3)
> > has been added to the pg_subscription_rel. Based pervious discussion and
> > document, that table seems shouldn't be refreshed when drop another
> > publication.
>
> Thanks for the explanation! I understood the problem.
>
> I've reviewed v2 patch. Here are some comments:

Regarding regression tests, since ADD/DROP PUBLICATION logic could be
complicated it seems to me that we can add tests to a new file, say
alter_sub_pub.pl, that includes some scenarios as I mentioned in the
previous message.

Regards,

-- 
Masahiko Sawada
EDB:  https://www.enterprisedb.com/



pgsql-hackers by date:

Previous
From: "Bossart, Nathan"
Date:
Subject: Re: archive status ".ready" files may be created too early
Next
From: Andrey Borodin
Date:
Subject: Re: Commitfest overflow