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 1n7524-0001jr-Mz for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Jan 2022 00:29:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n7522-0000V0-6G for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Jan 2022 00:28:58 +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 1n7521-0000Un-6A for pgsql-hackers@lists.postgresql.org; Tue, 11 Jan 2022 00:28:57 +0000 Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n751x-0001Mb-Rq for pgsql-hackers@postgresql.org; Tue, 11 Jan 2022 00:28:55 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id E754C5C010A; Mon, 10 Jan 2022 19:28:52 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 10 Jan 2022 19:28:52 -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=2L/44ikbj2Yy8QJ29mBsoDXPLZIZ7Citp8XmLKf3C+A=; b=Fj+fOqzG vrRf6GvYdfGfMXBc5LC3iNo+lIJKc5vMXiRWsI/2SSndYomZzCHGtObTWcQ41v1K ak+xJ8gA3FlLil0oLgDU+ioNZ5OTs3bbPPP2Fjjrqa59ZPTytYn8Iiw6xUvDz1Mp IqNok+AGvoXTuMM1ZCii9+2Xo78gvUOaWMdPtvRt4SzQ1aWTpglD1obQp08Ia7Td TWjGt/xBkuWvWuVewikyCgNsDAYWo6jtBii5KbNbJAkBnNN7T/sA8iItFClx8sKm LR68f0dCi/SI9mWUA+V45276O24bcJ0uXJLrDX11o2Y7gleE7qJvHQcS9nn2Bn4E +CijYEqRirTi/g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudehvddgvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpedujeevjeffjeevuddutedvkeeiueeitddvieelfeekveej udefgeeuvdejhfeuleenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 10 Jan 2022 19:28:52 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id D84142A0804; Mon, 10 Jan 2022 21:28:48 -0300 (-03) Date: Mon, 10 Jan 2022 21:28:48 -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: <202201110028.wicsx7ex2o6a@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2d6c8b74-bdef-767b-bdb6-29705985ed9c@enterprisedb.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022-Jan-07, Peter Eisentraut wrote: > ATExecReplicaIdentity(): Regarding the question of how to handle > REPLICA_IDENTITY_NOTHING: I see two ways to do this. Right now, the > approach is that the user can set the replica identity freely, and we > decide later based on that what we can replicate (e.g., no updates). > For this patch, that would mean we don't restrict what columns can be > in the column list, but we check what actions we can replicate based > on the column list. The alternative is that we require the column > list to include the replica identity, as the patch is currently doing, > which would mean that REPLICA_IDENTITY_NOTHING can be allowed since > it's essentially a set of zero columns. > > I find the current behavior a bit weird on reflection. If a user > wants to replicate on some columns and only INSERTs, that should be > allowed regardless of what the replica identity columns are. 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 ... -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "Before you were born your parents weren't as boring as they are now. They got that way paying your bills, cleaning up your room and listening to you tell them how idealistic you are." -- Charles J. Sykes' advice to teenagers