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 1ip8ze-0007m4-Ad for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Jan 2020 10:55:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ip8zc-0002bH-3t for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Jan 2020 10:55:16 +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 1ip8zb-0002b0-7K for pgsql-hackers@lists.postgresql.org; Wed, 08 Jan 2020 10:55:15 +0000 Received: from [64.147.123.24] (helo=wout1-smtp.messagingengine.com) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ip8zS-0004U8-Rx for pgsql-hackers@postgresql.org; Wed, 08 Jan 2020 10:55:14 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 7BFEB5C6; Wed, 8 Jan 2020 05:54:54 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 08 Jan 2020 05:54:54 -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=ifXzh7zoiw6+j/25F1grnzvZmG3Opa40PTqqUKCvp vY=; b=C33K4P37coLj70Nlr6gAfk6t3g2nA03pzY5fQ13ngPJZwfDKJ0ywrvJmj tMZuxOvFteRQ+i3ppJEoN3walu8beaoOpzMFw5vFYZvpUgHuZmG60B+yOSR0Rk1f wcsz+yje9Sns6nJ1Z6j03Ha+HiHqDA5qJLYihfAlllCTHaQIl+LnUsiFsu7dQJi3 IyaQQlwcN3oIjkz50A+2dAfJmChS16xEdL98Rxt7u1Q7ZrKVkvJAlbkjfz5fyi3V /e3zxxCGIIlbnkLy7TpATjABr8Umhfuu7bHu+dAMUpBMoOvS8lck84/B95stIldR KhB5g7ltB22FAvTJrcfTdaTjeRUxQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdehkedgvdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhohfkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpefrvght vghrucfgihhsvghnthhrrghuthcuoehpvghtvghrrdgvihhsvghnthhrrghuthesvdhnug hquhgrughrrghnthdrtghomheqnecuffhomhgrihhnpedvnhguqhhurggurhgrnhhtrdgt ohhmnecukfhppeelfedrvdegfedrudekjedrudeggeenucfrrghrrghmpehmrghilhhfrh homhepphgvthgvrhdrvghishgvnhhtrhgruhhtsedvnhguqhhurggurhgrnhhtrdgtohhm necuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from april.pezone.net (p5df3bb90.dip0.t-ipconnect.de [93.243.187.144]) by mail.messagingengine.com (Postfix) with ESMTPA id 3AA9B30607B0; Wed, 8 Jan 2020 05:54:53 -0500 (EST) Subject: Re: adding partitioned tables to publications To: Amit Langote , Rafia Sabih References: <7a23e60b-ffe8-bce1-5c44-db48d3bc163e@2ndquadrant.com> Cc: PostgreSQL-development From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: <825b31ea-ad9f-21d1-29b6-2a494513458d@2ndquadrant.com> Date: Wed, 8 Jan 2020 11:54:52 +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 X-Host-Lookup-Failed: Reverse DNS lookup failed for 64.147.123.24 (deferred) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-01-07 06:01, Amit Langote wrote: > On Mon, Jan 6, 2020 at 8:25 PM Rafia Sabih wrote: >> Hi Amit, >> >> I went through this patch set once again today and here are my two cents. > > Thanks Rafia. > > Rebased and updated to address your comments. Looking through 0001, I think perhaps there is a better way to structure some of the API changes. Instead of passing the root_target_rel to CheckValidResultRel() and CheckCmdReplicaIdentity(), which we only need to check the publication actions of the root table, how about changing GetRelationPublicationActions() to automatically include the publication information of the root table. Then we have that information in the relcache once and don't need to check the base table and the partition root separately at each call site (of which there is only one right now). (Would that work correctly with relcache invalidation?) Similarly, couldn't GetRelationPublications() just automatically take partitioning into account? We don't need the separation between GetRelationPublications() and GetRelationAncestorPublications(). This would also avoid errors of omission, for example the GetRelationPublications() call in ATPrepChangePersistence() doesn't take GetRelationAncestorPublications() into account. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services