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

From Amit Kapila
Subject Re: Data is copied twice when specifying both child and parent table in publication
Date
Msg-id CAA4eK1L=XzvgjtEs8sTo-3Z6K-eJ+hGG3KaO9Yvgnhu88BsN1A@mail.gmail.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  (Peter Smith <smithpb2250@gmail.com>)
List pgsql-hackers
On Fri, Mar 24, 2023 at 2:36 PM wangw.fnst@fujitsu.com
<wangw.fnst@fujitsu.com> wrote:
>
> On Fri, Mar 24, 2023 at 14:17 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> And I found there is a problem in the three back-branch patches (HEAD_v21_0002*,
> REL15_* and REL14_*):
> In the function fetch_table_list, we use pg_partition_ancestors to get the list
> of tables from the publisher. But the pg_partition_ancestors was introduced in
> v12, which means that if the publisher is v11 and the subscriber is v14+, this
> will cause an error.
>

Yeah, I am also not sure how to fix this for back-branches. I didn't
see any field report for this so I am hesitant to make any complicated
changes in back-branches that will deviate it from HEAD. Let's try to
fix it for HEAD at this stage. I have slightly modified the attached
patch, the changes are (a) I have removed the retail pfrees added in
pg_get_publication_tables() as that memory will anyway be freed when
we call SRF_RETURN_DONE(). It is also inconsistent to sometimes do
retail pfree and not other times in the same function. I have also
referred few similar functions and didn't find them doing retail
pfree. (b) Changed the comments in a few places.

The patch looks good to me. So, I am planning to push this sometime
early next week unless there are more suggestions or comments.

--
With Regards,
Amit Kapila.

Attachment

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Commitfest 2023-03 starting tomorrow!
Next
From: marekmosiewicz@gmail.com
Date:
Subject: Re: Disable vacuuming to provide data history