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 1n5pbP-00025b-8K for pgsql-hackers@arkaria.postgresql.org; Fri, 07 Jan 2022 13:48:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n5pbO-0003wo-3l for pgsql-hackers@arkaria.postgresql.org; Fri, 07 Jan 2022 13:48:18 +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 1n5pbM-0003tb-CV for pgsql-hackers@lists.postgresql.org; Fri, 07 Jan 2022 13:48:17 +0000 Received: from new3-smtp.messagingengine.com ([66.111.4.229]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n5pbE-00066y-Ur for pgsql-hackers@lists.postgresql.org; Fri, 07 Jan 2022 13:48:15 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.nyi.internal (Postfix) with ESMTP id 0A34A580514; Fri, 7 Jan 2022 08:48:07 -0500 (EST) Received: from imap49 ([10.202.2.99]) by compute5.internal (MEProxy); Fri, 07 Jan 2022 08:48:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eulerto.com; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm3; bh=uW0GZ0QBIF1YhBwBeLHfg8JyC57AkJY dedNVyttcjXQ=; b=mecSPaat1TtkTlEOBzuQcTm+aiYFSq1zcBRuMMC+DpvjDOO IAFzWd0/Qt7CnNqdCvuk8ORHpc8xkeEFGvjFqH3kvYsoJqsd+Wh/Qp8X43NP2DnR 0QvfyHKs6/kjpQHrWpqDeZQFgKuhAFS6/78ZzoKnJzfEKaHvRWstsTuTV3epOj1i noKSRucMnuRULZzrdAvqLpxWQey7DD52dn6ti+LZqdIMQqavBD1NdVhNffaceGVa AGiRUbCtcY6yTmlk1XFABSIEvTaybWSYCq1U4dbt6WpN9pgFRY/rcv5pAv7Rm1J3 SzXZIzoqnoYstAfAPCdZ2hE5PkCaDb3wY9xS9Gg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=uW0GZ0 QBIF1YhBwBeLHfg8JyC57AkJYdedNVyttcjXQ=; b=O7p7YEwjs8k8+CHmZ0cCn9 uBZ1rtIgo0O57O/2MS5mcWS713iPXg3ZPGeQqc3n7IEEX+0lm+wF1ibSyY4/w1sT F8JA2198PC4YNDPGR/kpRM/4ELQX3m42gP/BjsTeMACa8jAXPZMwwo+tVh+yJtQJ ykOROlOAyPU4maoymM0Cr03ycwMqgL4WANjEYsTDyl0C4dFut1obUe9poeaPUSK6 Rf4mqwofLFcOpNkmlQllp+ZcWaTyHsmrSZJkSxPOyQkLZ/F4L/FvyASJkZdUzP+c xfrS4uCm3GCj17NtCZhfd/CyA1km9N/3CEzxO3hRlCRnemBdqkv719qUaHYKeJpA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudegvddgfedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdfguhhl vghrucfvrghvvghirhgrfdcuoegvuhhlvghrsegvuhhlvghrthhordgtohhmqeenucggtf frrghtthgvrhhnpedtjeffieeuieeggeehieeutdevleetteejiedtgfehheefueekveff tedujefhffenucffohhmrghinhepphhoshhtghhrvghsqhhlrdhorhhgpdgvnhhtvghrph hrihhsvggusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpegvuhhlvghrsegvuhhlvghrthhordgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B051EF60075; Fri, 7 Jan 2022 08:48:06 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4526-gbc24f4957e-fm-20220105.001-gbc24f495 Mime-Version: 1.0 Message-Id: <344f4a31-e873-4aba-99ce-5503f19e56eb@www.fastmail.com> In-Reply-To: References: Date: Fri, 07 Jan 2022 10:47:44 -0300 From: "Euler Taveira" To: "Amit Kapila" Cc: "Peter Smith" , "houzj.fnst@fujitsu.com" , "Greg Nancarrow" , "vignesh C" , "Ajin Cherian" , "tanghy.fnst@fujitsu.com" , "Dilip Kumar" , "Rahila Syed" , "Peter Eisentraut" , =?UTF-8?Q?=C3=96nder_Kalac=C4=B1?= , japin , "Michael Paquier" , "David Steele" , "Craig Ringer" , "Amit Langote" , "PostgreSQL Hackers" Subject: Re: row filtering for logical replication Content-Type: multipart/alternative; boundary=b4a43b6b3e914f918f9b345fb0826112 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --b4a43b6b3e914f918f9b345fb0826112 Content-Type: text/plain On Fri, Jan 7, 2022, at 3:35 AM, Amit Kapila wrote: > On Fri, Jan 7, 2022 at 9:44 AM Amit Kapila wrote: > > > > On Thu, Jan 6, 2022 at 6:42 PM Euler Taveira wrote: > > > > > > IMO we shouldn't reuse ReorderBufferChangeType. For a long-term solution, it is > > > fragile. ReorderBufferChangeType has values that do not matter for row filter > > > and it relies on the fact that REORDER_BUFFER_CHANGE_INSERT, > > > REORDER_BUFFER_CHANGE_UPDATE and REORDER_BUFFER_CHANGE_DELETE are the first 3 > > > values from the enum, otherwise, it breaks rfnodes and no_filters in > > > pgoutput_row_filter(). > > > > > > > I think you mean to say it will break in pgoutput_row_filter_init(). I > > see your point but OTOH, if we do what you are suggesting then don't > > we need an additional mapping between ReorderBufferChangeType and > > RowFilterPublishAction as row filter and pgoutput_change API need to > > use those values. > > > > Can't we use 0,1,2 as indexes for rfnodes/no_filters based on change > type as they are local variables as that will avoid the fragileness > you are worried about. I am slightly hesitant to introduce new enum > when we are already using reorder buffer change type in pgoutput.c. WFM. I used numbers + comments in a previous patch set [1]. I suggested the enum because each command would be self explanatory. [1] https://www.postgresql.org/message-id/49ba49f1-8bdb-40b7-ae9e-f17d88b3afcd%40www.fastmail.com -- Euler Taveira EDB https://www.enterprisedb.com/ --b4a43b6b3e914f918f9b345fb0826112 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Fri, Jan 7, = 2022, at 3:35 AM, Amit Kapila wrote:
On Fri, Jan 7, 2022 at 9:44 AM Amit Kapila <= ;amit.kapila16@gmail.com&= gt; wrote:
>
> On Thu, Jan 6, 2022 at = 6:42 PM Euler Taveira <euler@eul= erto.com> wrote:
> >
> > = IMO we shouldn't reuse ReorderBufferChangeType. For a long-term solution= , it is
> > fragile. ReorderBufferChangeType has val= ues that do not matter for row filter
> > and it rel= ies on the fact that REORDER_BUFFER_CHANGE_INSERT,
> &g= t; REORDER_BUFFER_CHANGE_UPDATE and REORDER_BUFFER_CHANGE_DELETE are the= first 3
> > values from the enum, otherwise, it bre= aks rfnodes and no_filters in
> > pgoutput_row_filte= r().
> >
>
> I thi= nk you mean to say it will break in pgoutput_row_filter_init(). I
> see your point but OTOH, if we do what you are suggesting t= hen don't
> we need an additional mapping between Reord= erBufferChangeType and
> RowFilterPublishAction as row = filter and pgoutput_change API need to
> use those valu= es.
>

Can't we use 0,1,2 a= s indexes for rfnodes/no_filters based on change
type as t= hey are local variables as that will avoid the fragileness
you are worried about. I am slightly hesitant to introduce new enum
=
when we are already using reorder buffer change type in pgout= put.c.
WFM. I used numbers + comments in a pr= evious patch set [1]. I suggested the enum
because each co= mmand would be self explanatory.


=

-= -
Euler Taveira
EDB   ht= tps://www.enterprisedb.com/

--b4a43b6b3e914f918f9b345fb0826112--