Re: [BUG] wrong refresh when ALTER SUBSCRIPTION ADD/DROP PUBLICATION

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: Japin Li <japinli(at)hotmail(dot)com>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [BUG] wrong refresh when ALTER SUBSCRIPTION ADD/DROP PUBLICATION
Date: 2021-08-10 03:22:13
Message-ID: CAA4eK1Lju6BTVBS_Z1P5Obb8212-DkwKaKw-wnbgGixpeN+P_g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 10, 2021 at 8:05 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Sat, Aug 7, 2021 at 2:36 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Fri, Aug 6, 2021 at 9:57 PM Japin Li <japinli(at)hotmail(dot)com> wrote:
> > >
> > > >
> > > > Hmm yes, it cannot cover all cases. I had somehow misunderstood that
> > > > the subscriber knows which relations are associated with which
> > > > publications. Given that the subscriber doesn’t know which relations
> > > > are associated with which publications (and the set of subscribed
> > > > relations on the subscriber becomes out of date once the publication
> > > > is updated), I think it's impossible to achieve that DROP PUBLICATION
> > > > drops relations that are associated with only the publication being
> > > > dropped.
> > > >
> > > >> Do we have better ideas to fix or shall we just
> > > >> say that we will refresh based on whatever current set of relations
> > > >> are present in publication to be dropped?
> > > >
> > > > I don't have better ideas. It seems to me that it's prudent that we
> > > > accept the approach in v3 patch and refresh all publications in DROP
> > > > PUBLICATION cases.
> > > >
> > >
> > > Maybe refreshing all publications in PUBLICATION cases is simple way to
> > > fix the problem.
> > >
> >
> > Actually, doing it both will make the behavior consistent but doing it
> > just for Drop might be preferable by some users.
>
> I agree that ADD/DROP PUBLICATION is convenient to just add/drop
> publications instead of providing the complete publication list. But
> I'm concerned that during developing this feature most people didn't
> like the behavior of refreshing new and existing publications. Also,
> there was pointing out that there will be an overhead of a SQL with
> more publications when AlterSubscription_refresh() is called with all
> the existing publications.
>

True, but I think at that time we didn't know this design problem with
'drop publication'.

> If we feel this behavior is unnatural, the
> users will feel the same. I personally think there is a benefit only
> in terms of syntax.
>

Right, and I think in this particular case, the new syntax is much
easier to use for users.

> And we can work on the part of refreshing only
> publications being added/dropped on v15 development.
>

Yeah, unless we change design drastically we might not be able to do a
refresh for dropped publications, for add it is possible. It seems
most of the people responded on this thread that we can be consistent
in terms of refreshing for add/drop at this stage but we can still go
with another option where we can refresh only newly added publications
for add but for drop refresh all publications.

Peter E., do you have any opinion on this matter?

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-08-10 03:24:13 Re: alter table set TABLE ACCESS METHOD
Previous Message Masahiko Sawada 2021-08-10 02:35:17 Re: [BUG] wrong refresh when ALTER SUBSCRIPTION ADD/DROP PUBLICATION