Re: Logical Replication - behavior of ALTER PUBLICATION .. DROP TABLE and ALTER SUBSCRIPTION .. REFRESH PUBLICATION - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Logical Replication - behavior of ALTER PUBLICATION .. DROP TABLE and ALTER SUBSCRIPTION .. REFRESH PUBLICATION
Date
Msg-id CAA4eK1LfEqUq=VPK3MbKnSZOqVRELLOgc9MC9T7GFDYB0bQMEA@mail.gmail.com
Whole thread Raw
In response to Re: Logical Replication - behavior of ALTER PUBLICATION .. DROP TABLE and ALTER SUBSCRIPTION .. REFRESH PUBLICATION  (Li Japin <japinli@hotmail.com>)
List pgsql-hackers
On Thu, Jan 14, 2021 at 5:36 PM Li Japin <japinli@hotmail.com> wrote:
>
> On Jan 14, 2021, at 1:25 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> Attaching following two patches:
>
> 0001 - Makes publisher to not publish the changes for the alter
> publication ... dropped tables. Original patch is by japin, I added
> comments, changed the function name and adjusted the code a bit.
>
>
> Do we really need to access PUBLICATIONRELMAP in this patch? What if
> we just set it to false in the else condition of (if (publish &&
> (relkind != RELKIND_PARTITIONED_TABLE || pub->pubviaroot)))
>
>
> Thank for you review. I agree with you, it doesn’t need to access PUBLICATIONRELMAP, since
> We already get the publication oid in GetRelationPublications(relid) [1], which also access
> PUBLICATIONRELMAP.  If the current pub->oid does not in pubids, the publish is false, so we
> do not need publish the table.
>
> I have another question, the data->publications is a list, when did it has more then one items?
>
> 0001 - change as you suggest.
>

Can we add a test case for this patch as this seems to be a
reproducible bug? We can add the test in
src/test/subscription/100_bugs.pl unless you find a better place to
add it.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Remove PG_SHA*_DIGEST_STRING_LENGTH from sha2.h
Next
From: "Wang, Shenhao"
Date:
Subject: RE: invalid data in file backup_label problem on windows