Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iwMuU-0002r8-GZ for pgsql-hackers@arkaria.postgresql.org; Tue, 28 Jan 2020 09:11:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iwMuS-00087p-Vd for pgsql-hackers@arkaria.postgresql.org; Tue, 28 Jan 2020 09:11:48 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iwMuS-00086I-1Y for pgsql-hackers@lists.postgresql.org; Tue, 28 Jan 2020 09:11:48 +0000 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iwMuL-0006mK-HC for pgsql-hackers@postgresql.org; Tue, 28 Jan 2020 09:11:45 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 0064F609; Tue, 28 Jan 2020 04:11:37 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 28 Jan 2020 04:11:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=RlDJHHQD40RlqWSbNv5GLvK3Q1fS+/PFc3UTm9o1V yE=; b=E5thyqVYDLs5SLM1poh8GwPhn782KKnPvyYfekAT8EJbJELc6Lzlly1hm cleRR5M2NDLoUUm9DpIoeIuId1r08l9cjjq8N7XS6+3yHxkj0ibDh7Lz7bHcciwt fiGbTEpNkeKYt+ZtCmsCRMDrPjs9RTTsb1PnEq2nLJomPUiMe2dEOoeH/GjphYdP cs2JvJETymA2Y2A14lU8WBZEgPLd6esdbjG5YiWyqbKr9ZseybazW/UH3weodgHb APKjBbDUYnHRNYA9j6EPjOm8aU3yFe8tXgKJqa3OTHGZs2HgWHLIxzKxnKneJQPM qQphl3FQQT6alfjB24p98GwQh4jag== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrfeegucetufdoteggodetrfdotffvucfrrh hofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh epuffvfhfhohfkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpefrvghtvghrucfg ihhsvghnthhrrghuthcuoehpvghtvghrrdgvihhsvghnthhrrghuthesvdhnughquhgrug hrrghnthdrtghomheqnecuffhomhgrihhnpedvnhguqhhurggurhgrnhhtrdgtohhmnecu kfhppeelfedrvdegvddrvdehhedrudduvdenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehpvghtvghrrdgvihhsvghnthhrrghuthesvdhnughq uhgrughrrghnthdrtghomh X-ME-Proxy: Received: from april.pezone.net (p5df2ff70.dip0.t-ipconnect.de [93.242.255.112]) by mail.messagingengine.com (Postfix) with ESMTPA id A23B3306B683; Tue, 28 Jan 2020 04:11:36 -0500 (EST) Subject: Re: adding partitioned tables to publications To: Amit Langote References: <7a23e60b-ffe8-bce1-5c44-db48d3bc163e@2ndquadrant.com> <825b31ea-ad9f-21d1-29b6-2a494513458d@2ndquadrant.com> Cc: Rafia Sabih , PostgreSQL-development From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: Date: Tue, 28 Jan 2020 10:11:35 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-01-23 11:10, Amit Langote wrote: > On Wed, Jan 22, 2020 at 2:38 PM Amit Langote wrote: >> Other than that, the updated patch contains following significant changes: >> >> * Changed pg_publication.c: GetPublicationRelations() so that any >> published partitioned tables are expanded as needed >> >> * Since the pg_publication_tables view is backed by >> GetPublicationRelations(), that means subscriptioncmds.c: >> fetch_table_list() no longer needs to craft a query to include >> partitions when needed, because partitions are included at source. >> That seems better, because it allows to limit the complexity >> surrounding publication of partitioned tables to the publication side. >> >> * Fixed the publication table DDL to spot more cases of tables being >> added to a publication in a duplicative manner. For example, >> partition being added to a publication which already contains its >> ancestor and a partitioned tables being added to a publication >> (implying all of its partitions are added) which already contains a >> partition > On second thought, this seems like an overkill. It might be OK after > all for both a partitioned table and its partitions to be explicitly > added to a publication without complaining of duplication. IOW, it's > the user's call whether it makes sense to do that or not. This structure looks good now. However, it does seem unfortunate that in pg_get_publication_tables() we need to postprocess the result of GetPublicationRelations(). Since we're already changing the API of GetPublicationRelations(), couldn't we also make it optionally not include partitioned tables? For the test, perhaps add test cases where partitions are attached and detached so that we can see whether their publication relcache information is properly updated. (I'm not doubting that it works, but it would be good to have a test for, in case of future restructuring.) -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services