Message-ID: <eb7047d0-6db1-b526-f44a-fad58eda35d4@timescale.com>
Date: Fri, 17 Mar 2023 16:36:53 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.1
From: Jacob Champion <jchampion@timescale.com>
Subject: Re: Data is copied twice when specifying both child and parent table
 in publication
To: "wangw.fnst@fujitsu.com" <wangw.fnst@fujitsu.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Andres Freund
 <andres@anarazel.de>, vignesh C <vignesh21@gmail.com>,
 Peter Smith <smithpb2250@gmail.com>,
 "Takamichi Osumi (Fujitsu)" <osumi.takamichi@fujitsu.com>,
 "shiy.fnst@fujitsu.com" <shiy.fnst@fujitsu.com>,
 "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>,
 Amit Langote <amitlangote09@gmail.com>,
 Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
 "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
 Dilip Kumar <dilipbalaut@gmail.com>, Greg Nancarrow <gregn4422@gmail.com>
References: <OS3PR01MB62751414E4DABF144F5E481C9E529@OS3PR01MB6275.jpnprd01.prod.outlook.com>
 <CAHut+PtTN1Udug3x1eZnDdh8Z6PL5VN=xz1b44VbB9T1z_PtcQ@mail.gmail.com>
 <OS3PR01MB6275A9B8C65C381C6828DF9D9E549@OS3PR01MB6275.jpnprd01.prod.outlook.com>
 <CAHut+PvaSDuZ7PhzZOm4c2u-sbN4DUsZr22qyYQ8dncUpqMpXg@mail.gmail.com>
 <OS3PR01MB6275843B2BBE92870F7881C19E299@OS3PR01MB6275.jpnprd01.prod.outlook.com>
 <CAHut+Pt+1PNx6VsZ-xKzAU-18HmNXhjCC1TGakKX46Wg7YNT1Q@mail.gmail.com>
 <OS3PR01MB6275FB5397C6A647F262A3A69E009@OS3PR01MB6275.jpnprd01.prod.outlook.com>
 <CALDaNm3ZzNJ6Y1iX=PBYCcCU+EPm4=9LVXFin5gvQ9XkEzc8UQ@mail.gmail.com>
 <OS3PR01MB6275C62FF1D1CDE4FCBF61339E079@OS3PR01MB6275.jpnprd01.prod.outlook.com>
 <20230207202834.c2ptvco7dv57t3hi@awork3.anarazel.de>
 <OS3PR01MB62758DFA4FE5BFA7CA0815329ED89@OS3PR01MB6275.jpnprd01.prod.outlook.com>
 <CAA4eK1LCzvPLVHHXn+VcGmFHApKtbpaNF1UFed3qE8=GhPzPGw@mail.gmail.com>
 <OSZPR01MB62783EDCE9DDC21D35B789209EBD9@OSZPR01MB6278.jpnprd01.prod.outlook.com>
Content-Language: en-US
In-Reply-To: <OSZPR01MB62783EDCE9DDC21D35B789209EBD9@OSZPR01MB6278.jpnprd01.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/eb7047d0-6db1-b526-f44a-fad58eda35d4%40timescale.com>
Precedence: bulk

On Thu, Mar 16, 2023 at 11:28 PM wangw.fnst@fujitsu.com
<wangw.fnst@fujitsu.com> wrote:
> Attach the new patch set.

Hi,

I ran into this problem while hacking on [1], so thank you for tackling
it! I have no strong opinions on the implementation itself; I just want
to register a concern that the tests have not kept up with the
implementation complexity.

For example, the corner case mentioned in 0003, with multiple
publications having conflicting pubviaroot settings, isn't tested as far
as I can see. (I checked manually, and it appears to work as intended.)
And the related pub_lower_level test currently only covers the case
where multiple publications have pubviaroot=true, so the following test
comment is now misleading:

> # for tab4, we publish changes through the "middle" partitioned table
> $node_publisher->safe_psql('postgres',
> 	"CREATE PUBLICATION pub_lower_level FOR TABLE tab4_1 WITH (publish_via_partition_root = true)"
> );

...since the changes are now in fact published via the tab4 root after
this patchset is applied.

> I think the aim of joining it with pg_publication before is to exclude
> non-existing publications. Otherwise, we would get an error because of the call
> to function GetPublicationByName (with 'missing_ok = false') in function
> pg_get_publication_tables.

In the same vein, I don't think that case is covered anywhere.

There are a bunch of moving parts and hidden subtleties here, and I fell
into a few traps when I was working on my patch, so it'd be nice to have
additional coverage. I'm happy to contribute effort in that area if it's
helpful.

Thanks!
--Jacob

[1] https://postgr.es/m/dc57f088-039b-7a71-8f4c-082ef106246e%40timescale.com