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 1nk3EC-00011G-BM for pgsql-hackers@arkaria.postgresql.org; Thu, 28 Apr 2022 12:26:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nk3EA-0002Iy-A1 for pgsql-hackers@arkaria.postgresql.org; Thu, 28 Apr 2022 12:26:34 +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 1nk3EA-0002Ip-0G for pgsql-hackers@lists.postgresql.org; Thu, 28 Apr 2022 12:26:34 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nk3E6-0000zQ-Di for pgsql-hackers@lists.postgresql.org; Thu, 28 Apr 2022 12:26:33 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 29B915C00FB; Thu, 28 Apr 2022 08:26:28 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 28 Apr 2022 08:26:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1651148788; x=1651235188; bh=IHZNusedgffrD ER1utjZHpYdktkih7uF/PIIMzm0Ubo=; b=dyGC2SuLG6xQwidLHYikjFz4hWyW1 OW5bDTG9ufG4hHfyrteNrs5vvJtUfQn2laO7phF6kWOK/ujs4HTRaqvsNpiSWFR9 hsJbRO5JyoVGUEGJj42OqDnfw83SG4cvPDCCzcUwCk+SNiA1IUe/R9MV4Mx/AZHb DpC/oHEmQQ84nZduARo/H6DDlI6MBQEZsw/tWdatFeLJKdTidQmzyyMtm8SlEzDf RPfpaZF8EkKkTOMDdZb2FpEHFOO3xmpHv9+0Q3fsQCIGu58eba6DNspO+qYe4NEe Dj/qEZN1vqDbcTZwAJNYsQ4SfhX2TkXUvb4QZ+p33b6BowBJ3IPQ0y47Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudejgdehudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomheprfgvthgv rhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdrvghishgvnhhtrhgruhhtsegvnhhtvg hrphhrihhsvggusgdrtghomheqnecuggftrfgrthhtvghrnhepheelffeggedujeetiefh leetuddvieffhfffvdejvdffgeejkeduleduheduieefnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvrhdrvghishgvnhhtrhgruhht segvnhhtvghrphhrihhsvggusgdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 28 Apr 2022 08:26:26 -0400 (EDT) Message-ID: <39077967-c327-eddb-ac4b-7d64117944fb@enterprisedb.com> Date: Thu, 28 Apr 2022 14:26:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: bogus: logical replication rows/cols combinations Content-Language: en-US To: Amit Kapila , Alvaro Herrera Cc: Tomas Vondra , Pg Hackers References: <006d5ffc-1e7a-5cf2-c507-88eee6e0c14d@enterprisedb.com> <202204270943.4ol7indtwv3i@alvherre.pgsql> From: Peter Eisentraut In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 27.04.22 12:33, Amit Kapila wrote: > Currently, when the subscription has multiple publications, we combine > the objects, and actions of those publications. It happens for > 'publish_via_partition_root', publication actions, tables, column > lists, or row filters. I think the whole design works on this idea > even the initial table sync. I think it might need a major change > (which I am not sure about at this stage) if we want to make the > initial sync also behave similar to what you are proposing. If one publication says "publish if insert" and another publication says "publish if update", then the combination of that is clearly "publish if insert or update". Similarly, if one publication says "WHERE (foo)" and one says "WHERE (bar)", then the combination is "WHERE (foo OR bar)". But if one publication says "publish columns a and b if condition-X" and another publication says "publish columns a and c if not-condition-X", then the combination is clearly *not* "publish columns a, b, c if true". That is not logical, in the literal sense of that word. I wonder how we handle the combination of pub1: publish=insert WHERE (foo) pub2: publish=update WHERE (bar) I think it would be incorrect if the combination is pub1, pub2: publish=insert,update WHERE (foo OR bar).