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 1n7Rhu-0006m2-C4 for pgsql-hackers@arkaria.postgresql.org; Wed, 12 Jan 2022 00:41:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n7Rht-0000gX-8z for pgsql-hackers@arkaria.postgresql.org; Wed, 12 Jan 2022 00:41:41 +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 1n7Rhs-0000gO-DN for pgsql-hackers@lists.postgresql.org; Wed, 12 Jan 2022 00:41:41 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n7Rho-0000kZ-1U for pgsql-hackers@postgresql.org; Wed, 12 Jan 2022 00:41:40 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 444D55C014D; Tue, 11 Jan 2022 19:41:32 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 11 Jan 2022 19:41:32 -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=w13yaecp0JiKtUORt+Pdm04hJ7xHIrKflc9YCwvlE/0=; b=XZD4Rg2j vk8MhzyYAcF7KgOZp/BlSbgeRuSN4+HVxz0cYkxrx19Q8wfrY4/8AiUYFL+4apfw t9dD+THDL6Kqs1jUWzojIf45DdfuzLfF8IwVw1Ldl2+7sut2vQB1/ErqN2nc0X7p 9umza8gw7Fm4LuMCJbYkI82/mGz8wE/qlUwh6u3usxYNTlQHtfTmFl6kNpQUDyRK 6IR1kbgsquOJ7RYJ51sE1/DttObN06fDoHgtMuLMMsv3RHCLBRlavU+xmPcDc2p+ ZTX8+lKB2BWeXl2jUPR/a1/4uQZbA7MaGyUaBnbFbn53Bodsszxk7VVsUjvIkohe e4VeU9fFVUeWTA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudehgedgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpedujeevjeffjeevuddutedvkeeiueeitddvieelfeekveej udefgeeuvdejhfeuleenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 11 Jan 2022 19:41:31 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 5547B2A0CA5; Tue, 11 Jan 2022 21:41:28 -0300 (-03) Date: Tue, 11 Jan 2022 21:41:28 -0300 From: Alvaro Herrera To: Peter Eisentraut Cc: Justin Pryzby , Tomas Vondra , Amit Kapila , "houzj.fnst@fujitsu.com" , Rahila Syed , Peter Smith , pgsql-hackers@postgresql.org Subject: Re: Column Filtering in Logical Replication Message-ID: <202201120041.p24wvsfcsope@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <202201111852.sg6v76xr6qkh@alvherre.pgsql> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022-Jan-11, Alvaro Herrera wrote: > On 2022-Jan-10, Alvaro Herrera wrote: > > > Hmm. So you're saying that we should only raise errors about the column > > list if we are publishing UPDATE or DELETE, but otherwise let the > > replica identity be anything. OK, I'll see if I can come up with a > > reasonable set of rules ... > > This is an attempt to do it that way. Now you can add a table to a > publication without regards for how column filter compares to the > replica identity, as long as the publication does not include updates > and inserts. I discovered a big hole in this, which is that ALTER PUBLICATION SET (publish='insert,update') can add UPDATE publishing to a publication that was only publishing INSERTs. It's easy to implement a fix: in AlterPublicationOptions, scan the list of tables and raise an error if any of them has a column list that doesn't include all the columns in the replica identity. However, that proposal has an ugly flaw: there is no index on pg_publication_rel.prpubid, which means that the only way to find the relations we need to inspect is to seqscan pg_publication_rel. Also, psql's query for \dRp+ uses a seqscan in pg_publication_rel. Therefore, I propose to add an index on pg_publication_rel.prpubid. -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/ "¿Qué importan los años? Lo que realmente importa es comprobar que a fin de cuentas la mejor edad de la vida es estar vivo" (Mafalda)