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

From Amit Kapila
Subject Re: [BUG] wrong refresh when ALTER SUBSCRIPTION ADD/DROP PUBLICATION
Date
Msg-id CAA4eK1Lju6BTVBS_Z1P5Obb8212-DkwKaKw-wnbgGixpeN+P_g@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>)
Responses Re: [BUG] wrong refresh when ALTER SUBSCRIPTION ADD/DROP PUBLICATION  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
On Tue, Aug 10, 2021 at 8:05 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Sat, Aug 7, 2021 at 2:36 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Fri, Aug 6, 2021 at 9:57 PM Japin Li <japinli@hotmail.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.



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [BUG] wrong refresh when ALTER SUBSCRIPTION ADD/DROP PUBLICATION
Next
From: Amit Kapila
Date:
Subject: Re: Small documentation improvement for ALTER SUBSCRIPTION