Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jJysu-0008LB-Rv for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Apr 2020 12:23:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jJyst-00008c-Cm for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Apr 2020 12:23:47 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jJyss-0008UM-DO for pgsql-hackers@lists.postgresql.org; Thu, 02 Apr 2020 12:23:47 +0000 Received: from [66.111.4.28] (helo=out4-smtp.messagingengine.com) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jJysn-0002cV-Ro for pgsql-hackers@postgresql.org; Thu, 02 Apr 2020 12:23:45 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0BEDC5C0249; Thu, 2 Apr 2020 08:23:30 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 02 Apr 2020 08:23:30 -0400 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=fm2; bh=DYs8v3lvXNtQR3NxROn/lW5Wa8h8i1g9TqFWCkDAt 2I=; b=xoM443CnySKgjfISzIgF8XwDLEfM8oMQtGL8NIm4XXMLCnaJxNumRKvJK NYnJiE8dLn9U/hlEqcwnYNEJ0DV6OCq3pT26msCp2HcZup4zzLwDVp5/ufLMQg6v r51cTiSnbMzSvLf2s9/+V2095tELaq8+sdt3iut1m7PBrfosRwK+D8el0H1VsNRq ZePZIDAoNQq9fD3FUJOviEP0yUs8edCs4fzFy44gbmWs6wqZfH3pwniYfyguFX4E OZStibrcnfMjwOli/xKwyxvQeT9L8i8GFIZULOuRw2i8LZwZQYcP//1IU8KRcht4 Zz1jkVpjpfAcrtF2GYbGBPKx1SEbg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrtdeggdegiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhfhokffffgggjggtgfesthejredttdefjeenucfhrhhomheprfgvthgv rhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdrvghishgvnhhtrhgruhhtsedvnhguqh hurggurhgrnhhtrdgtohhmqeenucffohhmrghinhepvdhnughquhgrughrrghnthdrtgho mhenucfkphepleefrddvgedvrddvudefrddvgedunecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvrhdrvghishgvnhhtrhgruhhtsedv nhguqhhurggurhgrnhhtrdgtohhm X-ME-Proxy: Received: from april.pezone.net (p5df2d5f1.dip0.t-ipconnect.de [93.242.213.241]) by mail.messagingengine.com (Postfix) with ESMTPA id C911D3280060; Thu, 2 Apr 2020 08:23:28 -0400 (EDT) Subject: Re: adding partitioned tables to publications To: Amit Langote References: <73a1877a-6f1d-9f2e-da51-bc2eb57e07d5@2ndquadrant.com> Cc: Rafia Sabih , PostgreSQL-development From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: <4f999141-97c8-c968-a726-0a1ec3e36e47@2ndquadrant.com> Date: Thu, 2 Apr 2020 14:23:27 +0200 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 X-Host-Lookup-Failed: Reverse DNS lookup failed for 66.111.4.28 (deferred) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-03-30 17:42, Amit Langote wrote: > I have updated the comments in apply_handle_tuple_routing() (see 0002) > to better explain what's going on with UPDATE handling. I also > rearranged the tests a bit for clarity. > > Attached updated patches. Test coverage for 0002 is still a bit lacking. Please do a coverage build yourself and get at least one test case to exercise every branch in apply_handle_tuple_routing(). Right now, I don't see any coverage for updates without attribute remapping and updates that don't move to a new partition. Also, the coverage report reveals that in logicalrep_partmap_init(), the patch is mistakenly initializing LogicalRepRelMapContext instead of LogicalRepPartMapContext. (Hmm, how does it even work like that?) I think apart from some of these details, this patch is okay, but I don't have deep experience in the partitioning code, I can just see that it looks like other code elsewhere. Perhaps someone with more knowledge can give this a look as well. About patch 0003, I was talking to some people offline about the name of the option. There was some confusion about using the term "schema". How about naming it "publish_via_partition_root", which also matches the name of the analogous option in pg_dump. Code coverage here could also be improved. A lot of the new code in pgoutput.c is not tested. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services