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

From Amit Kapila
Subject Re: pg_get_publication_tables() output duplicate relid
Date
Msg-id CAA4eK1+NoB7M+Weg=CKxJn-r8ToTJxUkJxhCDtvOq=1P-a5exA@mail.gmail.com
Whole thread Raw
In response to Re: pg_get_publication_tables() output duplicate relid  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: pg_get_publication_tables() output duplicate relid
List pgsql-hackers
On Thu, Dec 2, 2021 at 8:42 AM Amit Langote <amitlangote09@gmail.com> wrote:
>
> On Thu, Dec 2, 2021 at 9:44 houzj.fnst@fujitsu.com
> <houzj.fnst@fujitsu.com> wrote:
> > On Wed, Dec 1, 2021 3:01 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > > > > On Mon, Nov 22, 2021 at 12:55 PM Amit Langote
> > > > > <amitlangote09@gmail.com> wrote:
> > > > > > On second thought, I agree that de-duplicating partitions from
> > > > > > this view is an improvement.
> > > > >
> > > > > Fair enough. Hou-San, Can you please submit the updated patch after
> > > > > fixing any pending comments including the test case?
> > > >
> > > > Attach the updated patch which address the comments so far.
> > > >
> > > > The patch only adds a testcase in publication.sql because the
> > > > duplicate output doesn't cause unexpected behavior in pub-sub test.
> > >
> > > Thanks, the patch looks good to me. I have slightly changed the commit
> > > message in the attached. I would like to commit this only in HEAD as there is no
> > > user complaint about this and it might not stop any user's service unless it relies
> > > on this view's output for the initial table synchronization.
>
> The patch looks good to me too in that it gets the job done.
>
> Reading Alvaro's email at the top again gave me a pause to reconsider
> what I had said in reply.  It might indeed have been nice if the
> publication DDL itself had prevented the cases where a partition and
> its ancestor are added to a publication, though as Hou-san mentioned,
> partition ATTACHes make that a bit tricky to enforce at all times,
> though of course not impossible.  Maybe it's okay to just de-duplicate
> pg_publication_tables output as the patch does, even though it may
> appear to be a band-aid solution if we one considers Alvaro's point
> about consistency.
>

True, I think even if we consider that idea it will be a much bigger
change, and also as it will be a behavioral change so we might want to
keep it just for HEAD and some of these fixes need to be backpatched.
Having said that, if you or someone want to pursue that idea and come
up with a better solution than what we have currently it is certainly
welcome.


> > > What do you think?
> > I agreed that we can commit only in HEAD.
>
> +1 to do this only in HEAD.
>

Okay, If there are no further suggestions or objections, I'll commit
the patch early next week (mostly by Monday).

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: GUC flags
Next
From: Darafei "Komяpa" Praliaskouski
Date:
Subject: Re: BUG #17302: gist index prevents insertion of some data