RE: pg_get_publication_tables() output duplicate relid
Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
From: "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Amit Langote <amitlangote09@gmail.com>
Date: 2022-04-18T06:25:49Z
Lists: 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
Commits
-
Improve invalidation handling in pgoutput.c.
- 7f481b8d3884 15.0 cited
-
De-duplicate the result of pg_publication_tables view.
- a61bff2bf479 15.0 landed
-
Doc: Add "Attach Partition" limitation during logical replication.
- 64e8456bbde1 13.6 landed
- 4b8eec716a52 14.2 landed
- eb7828f54a44 15.0 landed