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

From houzj.fnst@fujitsu.com
Subject RE: pg_get_publication_tables() output duplicate relid
Date
Msg-id OS0PR01MB571645561E3ABFDD6C75BA2194699@OS0PR01MB5716.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: pg_get_publication_tables() output duplicate relid  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: pg_get_publication_tables() output duplicate relid
List pgsql-hackers
On Wed, Dec 1, 2021 3:01 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Mon, Nov 29, 2021 at 2:37 PM houzj.fnst@fujitsu.com
> <houzj.fnst@fujitsu.com> wrote:
> >
> > On Wed, Nov 24, 2021 4:48 PM Amit Kapila <amit.kapila16@gmail.com>
> > > On Mon, Nov 22, 2021 at 12:55 PM Amit Langote
> > > <amitlangote09@gmail.com>
> > > wrote:
> > > >
> > > > On Fri, Nov 19, 2021 at 2:28 PM Amit Kapila
> > > > <amit.kapila16@gmail.com>
> > > wrote:
> > > > > On Fri, Nov 19, 2021 at 7:19 AM Amit Langote
> > > > > <amitlangote09@gmail.com>
> > > wrote:
> > > > > >  As in,
> > > > > > do we know of any replication (initial/streaming) misbehavior
> > > > > > caused by the duplicate partition OIDs in this case or is the
> > > > > > only problem that pg_publication_tables output looks odd?
> > > > >
> > > > > The latter one but I think either we should document this or
> > > > > change it as we can't assume users will follow what subscriber-side
> > > > > code does.
> > > >
> > > > 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.
> 
> What do you think?
I agreed that we can commit only in HEAD.

Best regards,
Hou zj


pgsql-hackers by date:

Previous
From: "Bossart, Nathan"
Date:
Subject: Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file
Next
From: Justin Pryzby
Date:
Subject: Re: BUFFERS enabled by default in EXPLAIN (ANALYZE)