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 1m4VUm-0005Ot-KZ for pgsql-hackers@arkaria.postgresql.org; Fri, 16 Jul 2021 21:35:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m4VUl-0002Mj-Ip for pgsql-hackers@arkaria.postgresql.org; Fri, 16 Jul 2021 21:35:43 +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 1m4VUk-0002Ma-PD for pgsql-hackers@lists.postgresql.org; Fri, 16 Jul 2021 21:35:43 +0000 Received: from new4-smtp.messagingengine.com ([66.111.4.230]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m4VUi-0007C1-AH for pgsql-hackers@lists.postgresql.org; Fri, 16 Jul 2021 21:35:41 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 770FE580397; Fri, 16 Jul 2021 17:35:38 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 16 Jul 2021 17:35:38 -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=7JY2Jse+GvGivNZ6DbbeM9WotM/mu5YJD4BY/niaKF4=; b=HDoBZZwX AMoxe0AP1vhJkkwKwYAcNZFbHEJBnh+FWTpEwq6Y5m/rywy5oPnzifh3kYQrEJjC 9ZIVbSsdYzbcWpcuhgTmwOsC0ojET+8+ApQHr6rSq6BA67QHLMmT9KPoXNIkNWTD k1SrQ2poDTwxt4X+rnYLiXfduOMuzoGO4loe9Sni/cwpnVC3maJ+tWaW1OY5is2h gF+9Hyc4xjE9xmWawsTM7ij9qDBFeQy7GbvmpXgBzdwzCzvoZz4Lbj8CXXS7vumj UeBG+Ql1PhpNxX9/e4g4I0c6FKVXHO6mJQt3m4kA1rpFpOZ2gY3OzOgTTVNFs7ZT FzXHjt+9t7GryA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdefgddufeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpedujeevjeffjeevuddutedvkeeiueeitddvieelfeekveej udefgeeuvdejhfeuleenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 16 Jul 2021 17:35:37 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 746DA2A097C; Fri, 16 Jul 2021 17:35:33 -0400 (-04) Date: Fri, 16 Jul 2021 17:35:33 -0400 From: Alvaro Herrera To: Greg Nancarrow Cc: Amit Kapila , Dilip Kumar , Tomas Vondra , Euler Taveira , Peter Smith , Rahila Syed , Peter Eisentraut , =?utf-8?B?w5ZuZGVyIEthbGFjxLE=?= , japin , Michael Paquier , David Steele , Craig Ringer , Tomas Vondra , Amit Langote , PostgreSQL Hackers Subject: Re: row filtering for logical replication Message-ID: <202107162135.m5ehijgcasjk@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 2021-Jul-16, Greg Nancarrow wrote: > On Fri, Jul 16, 2021 at 3:50 PM Amit Kapila wrote: > > > > I am not so sure about different filters for old and new rows but it > > makes sense to by default apply the filter to both old and new rows. > > Then also provide a way for user to specify if the filter can be > > specified to just old or new row. > > I'm having some doubts and concerns about what is being suggested. Yeah. I think the idea that some updates fail to reach the replica, leaving the downstream database in a different state than it would be if those updates had reached it, is unsettling. It makes me wish we raised an error at UPDATE time if both rows would not pass the filter test in the same way -- that is, if the old row passes the filter, then the new row must be a pass as well. Maybe a second option is to have replication change any UPDATE into either an INSERT or a DELETE, if the old or the new row do not pass the filter, respectively. That way, the databases would remain consistent. -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/ "You're _really_ hosed if the person doing the hiring doesn't understand relational systems: you end up with a whole raft of programmers, none of whom has had a Date with the clue stick." (Andrew Sullivan)