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 OS0PR01MB5716FE48063253C8B6634E2594F39@OS0PR01MB5716.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: pg_get_publication_tables() output duplicate relid  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On Friday, April 15, 2022 12:46 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> 
> On 2022-Apr-11, houzj.fnst@fujitsu.com wrote:
> 
> > I have confirmed that the bug of ATTACH PARTITION has been fixed due to
> recent
> > commit 7f481b8. Currently, we always invalidate the RelationSyncCache when
> > attaching a partition, so the pubactions of the newly attached partition will
> > be rebuilt correctly.
> 
> Hm, this commit was not backpatched -- it is only in master.  I just
> checked that pg14 behaves as you describe in the opening email of this
> thread; did we decide that we don't want to change behavior of stable
> branches?

Hi,

Do you mean the original bug: "pg_get_publication_tables function will output
duplicate partition relid when adding both child and parent table to the
publication(pubviaroot = false). " ?

We decided to commit the fix for it 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.

Or do you mean another one mentioned here which is "the changes on newly
attached partition won't be replicated" ? For this one, I think it's fine to
backpatch the fix and I can prepare the patch for back branches if needed. BTW,
if we want to backpatch this fix we might need to keep the order of
RelationSyncEntry struct member unchanged in back branches.

Best regards,
Hou zj

pgsql-hackers by date:

Previous
From: "wangw.fnst@fujitsu.com"
Date:
Subject: RE: Logical replication timeout problem
Next
From: Michael Paquier
Date:
Subject: Re: New Object Access Type hooks