Re: pg_get_publication_tables() output duplicate relid - Mailing list pgsql-hackers

From Amit Langote
Subject Re: pg_get_publication_tables() output duplicate relid
Date
Msg-id CA+HiwqFSy7=vBVYx7XqqAWZ9eNdwUrLPDY8kTFyNsM=Mw2hobg@mail.gmail.com
Whole thread Raw
In response to Re: pg_get_publication_tables() output duplicate relid  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Tue, Dec 7, 2021 at 12:45 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Mon, Dec 6, 2021 at 8:04 PM Amit Langote <amitlangote09@gmail.com> wrote:
> > So IIUC the scenario of concern is when a table to be attached as a
> > partition is in a schema that's present in pg_publication_namespace.
> > The only way to stop it from being published is to move it to another
> > schema that is not published using that publication.
> >
> > I think I misunderstood how the IN SCHEMA feature works.
> > Specifically, I didn't know that one can add a partitioned table to
> > the same publication (or any table other than those in a particular
> > schema for that matter).  Then the attached partition would still be
> > present in the publication by way of being part of the schema that is
> > present in the publication, along with the partitioned table that is
> > added separately.
>
> Right.
>
> > Yes, my proposal in its current form can't prevent that kind of duplication.
>
> I am not sure how to proceed here. I feel it is better to go ahead
> with the fix Hou-san proposed here and in another email [1] to fix the
> know issues, especially because the issue discussed in [1] needs to be
> back-patched.
>
> We can evaluate your proposal separately for HEAD. What
> do you think?

Yeah, maybe.  Though given the direction that the row-filters patch
set is taking in allowing to definw filters on the individual
partitions, I am not sure if I should be pushing the approach to
disallow partitions from being added to publications explicitly
alongside their parent tables.  I'll try to take a look at that thread
to be sure if that's actually the case.

Also, for the purposes of the problems that Greg and Hou-san have
discovered, I have no objection with applying Hou-san's patches.
Those seem better for the back-patching anyway.

Thank you.

-- 
Amit Langote
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Nikolay Samokhvalov
Date:
Subject: Re: Add sub-transaction overflow status in pg_stat_activity
Next
From: Amit Kapila
Date:
Subject: Re: Fix a bug in DecodeAbort() and improve input data check on subscriber.