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 1m0uiX-0004qC-O4 for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Jul 2021 23:43:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m0uiW-0003tc-Cz for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Jul 2021 23:43:04 +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 1m0uiV-0003tU-Kg for pgsql-hackers@lists.postgresql.org; Tue, 06 Jul 2021 23:43:04 +0000 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m0uiR-0003st-KB for pgsql-hackers@postgresql.org; Tue, 06 Jul 2021 23:43:03 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 354AD3200754; Tue, 6 Jul 2021 19:42:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Tue, 06 Jul 2021 19:42:55 -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:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=P+THs9jo0UNEMM9C74lypjPcBz3KsuzfQT9Ce2T5rlU=; b=i/UzsGvr Sfz7yumFrcVH62UNMRpPBK+OO4+/c91AtYsJ8Ny0Z5k20ohaYQkX6sj1pi7ykDv2 cIM1lFDYTVLv4bLzHlJfIZHzbshYhTgaTTjvL/hd78/h05CYUN81s6sqniIkM8B3 3ktWzu370ec4RgZ9pRLRz+foauZOpTiWCo4gnsOaheS1F7tnwz/NmWt5T/dUqfTi EUbmRvbxzciWWbdpDwEnOCL/4p1eBPz3GHUR8CUvmV+M1Yhj65naZEKoFITWb08F vOV6dmPssbFCOpGOFc2Iplacui/vIMndZG/FI4bcV8+9UiiB/OqQtIarvgqwn94M xeVQkVWDIsYANg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrtddugdduiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgrrhho ucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgheqne cuggftrfgrthhtvghrnhepudejveejffejveduudetvdekieeuiedtvdeileefkeevjedu feeguedvjefhueelnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomhenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgv rhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 6 Jul 2021 19:42:54 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 658902A223F; Tue, 6 Jul 2021 19:42:51 -0400 (-04) Date: Tue, 6 Jul 2021 19:42:51 -0400 From: Alvaro Herrera To: Rahila Syed Cc: PostgreSQL-development Subject: Re: Column Filtering in Logical Replication Message-ID: <202107062342.eq6htmp2wgp2@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 Hello, here are a few comments on this patch. The patch adds a function get_att_num_by_name; but we have a lsyscache.c function for that purpose, get_attnum. Maybe that one should be used instead? get_tuple_columns_map() returns a bitmapset of the attnos of the columns in the given list, so its name feels wrong. I propose get_table_columnset(). However, this function is invoked for every insert/update change, so it's going to be far too slow to be usable. I think you need to cache the bitmapset somewhere, so that the function is only called on first use. I didn't look very closely, but it seems that struct RelationSyncEntry may be a good place to cache it. The patch adds a new parse node PublicationTable, but doesn't add copyfuncs.c, equalfuncs.c, readfuncs.c, outfuncs.c support for it. Maybe try a compile with WRITE_READ_PARSE_PLAN_TREES and/or COPY_PARSE_PLAN_TREES enabled to make sure everything is covered. (I didn't verify that this actually catches anything ...) The new column in pg_publication_rel is prrel_attr. This name seems at odds with existing column names (we don't use underscores in catalog column names). Maybe prattrs is good enough? prrelattrs? We tend to use plurals for columns that are arrays. It's not super clear to me that strlist_to_textarray() and related processing will behave sanely when the column names contain weird characters such as commas or quotes, or just when used with uppercase column names. Maybe it's worth having tests that try to break such cases. You seem to have left a debugging "elog(LOG)" line in OpenTableList. I got warnings from "git am" about trailing whitespace being added by the patch in two places. Thanks! -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/