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 1n5RnT-00082V-EF for pgsql-hackers@arkaria.postgresql.org; Thu, 06 Jan 2022 12:23:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n5RnR-000209-Hn for pgsql-hackers@arkaria.postgresql.org; Thu, 06 Jan 2022 12:23:09 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n5RnQ-000200-Ds for pgsql-hackers@lists.postgresql.org; Thu, 06 Jan 2022 12:23:09 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n5RnJ-0002tH-BM for pgsql-hackers@postgresql.org; Thu, 06 Jan 2022 12:23:07 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 4C1C15C00AE; Thu, 6 Jan 2022 07:22:59 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 06 Jan 2022 07:22:59 -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:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=x4rWR+m+SWCnVaPu27QtsFIP4cVU+FhnaO2X6dZVZlI=; b=X1ifNxNF wmxLB4PWgWiNMyGPkT26Qj/ls33K/erXCs8uEmEUDiPNgGGeC4TqzUh9yDESMYmb 3iWPhEwbZrXyoCXxlUAFHGP3KJuv2Ihz5gID4z28bAykUOZJyXqk7LvI5hqgPYks D5f4En70o3Uw3+CjShBJG27eOBNtdWwhxDqiydH4hHdugAyLbO0la/+NrDs8NG5L AfrGDoXxkGXVT4+K2VwH+7cW/er878Kx1LPlNCj644ZF0gvL3F9NUpCXwfw+zbnR yVqNG7x770iDo0+cCwbBHnejyaOVBOtl/dsdZBEQfwbwHTrr2xuyfLU30doFI3/0 V1uDxec8ZOXBEQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudefledgfeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpedujeevjeffjeevuddutedvkeeiueeitddvieelfeekveej udefgeeuvdejhfeuleenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 6 Jan 2022 07:22:58 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id B6FCF2A073A; Thu, 6 Jan 2022 09:22:54 -0300 (-03) Date: Thu, 6 Jan 2022 09:22:54 -0300 From: Alvaro Herrera To: Amit Kapila Cc: Justin Pryzby , Tomas Vondra , Peter Eisentraut , "houzj.fnst@fujitsu.com" , Rahila Syed , Peter Smith , pgsql-hackers Subject: Re: Column Filtering in Logical Replication Message-ID: <202201061222.2xphgufwsf23@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022-Jan-06, Amit Kapila wrote: > On Mon, Jan 3, 2022 at 8:01 PM Alvaro Herrera wrote: > > > > fetch_remote_table_info() > { > .. > + appendStringInfo(&cmd, > + " SELECT pg_catalog.unnest(prattrs)\n" > + " FROM pg_catalog.pg_publication p JOIN\n" > + " pg_catalog.pg_publication_rel pr ON (p.oid = pr.prpubid)\n" > + " WHERE p.pubname IN (%s) AND\n", > + publications.data); > + if (!am_partition) > + appendStringInfo(&cmd, "prrelid = %u", lrel->remoteid); > + else > + appendStringInfo(&cmd, > + "prrelid IN (SELECT relid\n" > + " FROM pg_catalog.pg_partition_tree(pg_catalog.pg_partition_root(%u)))", > + lrel->remoteid); > > IIUC, this doesn't deal with cases when some publication has not > specified table attrs. In those cases, I think it should return all > attrs? Hmm, no, the idea here is that the list of columns should be null; the code that uses this result is supposed to handle a null result to mean hat all columns are included. > Also, it is not very clear to me what exactly we want to do > with partitions? ... Hmm, maybe there is a gap in testing here, I'll check; but the idea is that we would use the column list of the most immediate ancestor that has one, if the partition itself doesn't have one. (I see we're missing a check for "pubviaroot", which should represent an override. Need more tests here.) -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "Uno puede defenderse de los ataques; contra los elogios se esta indefenso"