RE: Data is copied twice when specifying both child and parent table in publication - Mailing list pgsql-hackers

From osumi.takamichi@fujitsu.com
Subject RE: Data is copied twice when specifying both child and parent table in publication
Date
Msg-id TYCPR01MB837354021AFB263ABA238891ED5D9@TYCPR01MB8373.jpnprd01.prod.outlook.com
Whole thread Raw
In response to RE: Data is copied twice when specifying both child and parent table in publication  ("wangw.fnst@fujitsu.com" <wangw.fnst@fujitsu.com>)
Responses RE: Data is copied twice when specifying both child and parent table in publication  ("wangw.fnst@fujitsu.com" <wangw.fnst@fujitsu.com>)
List pgsql-hackers
On Wednesday, September 28, 2022 5:36 PM Wang, Wei/王 威 <wangw.fnst@fujitsu.com> wrote:
> Also rebased the patch because the change in the HEAD (20b6847).
> 
> Attach the new patches.
Hi, thank you for the updated patches!


Here are my minor review comments for HEAD v12.

(1) typo & suggestion to reword one comment


+                        * Publications support partitioned tables. If
+                        * publish_via_partition_root is false, all changes are replicated
+                        * using leaf partition identity and schema, so we only need
+                        * those. Otherwise, If publish_via_partition_root is true, get
+                        * the partitioned table itself.


The last sentence has "If" in the middle of the sentence.
We can use the lower letter for it. Or, I think "Otherwise" by itself means
"If publish_via_partition_root is true". So, I'll suggest a below change.


FROM:
Otherwise, If publish_via_partition_root is true, get the partitioned table itself.
TO:
Otherwise, get the partitioned table itself.


(2) Do we need to get "attnames" column from the publisher in the fetch_table_list() ?

When I was looking at v16 path, I didn't see any codes that utilize
the "attnames" column information returned from the publisher.
If we don't need it, could we remove it ?
I can miss something greatly, but this might be affected by HEAD codes ?



Best Regards,
    Takamichi Osumi


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: shadow variables - pg15 edition
Next
From: Tom Lane
Date:
Subject: Re: Startup process on a hot standby crashes with an error "invalid memory alloc request size 1073741824" while replaying "Standby/LOCK" records