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 1ma7ek-0007qq-TI for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Oct 2021 02:36:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ma7ej-0005uN-SQ for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Oct 2021 02:36: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 1ma7bg-0000ov-B0 for pgsql-hackers@lists.postgresql.org; Tue, 12 Oct 2021 02:33:32 +0000 Received: from mail-ed1-x52c.google.com ([2a00:1450:4864:20::52c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ma7ba-0005rf-0B for pgsql-hackers@lists.postgresql.org; Tue, 12 Oct 2021 02:33:31 +0000 Received: by mail-ed1-x52c.google.com with SMTP id i20so58520650edj.10 for ; Mon, 11 Oct 2021 19:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I/oQJBrzI8ra4O0kLYc3DHwP3f+1ifcyyKJhpThm+/w=; b=mUYa4bxImBOk0wKAABP6zgI1IVd/sxjO5iNEPuDOhvd2DaGxONFiPKix8Z3feE9+BL 7+nyyrWTysHBuhJkTDyXrwObwGED6C09YvcB/QYT5+1RWRB4nnDYtLhmjOdAn7hQPWQd SvwaLLIIBqSss+DDXMBLJahnyUwOMA8UT5zBPJ7aManmxF9zJNsfmeZUIwfpRuzUoJiY D3bD2Hu4REiwzrQq+vn2o3mexQoleEdw0Fcz2DEX6OSkPwk3mwHxrZd7YUXhBWIf1M/5 zc1U14Hgl6t/dYFjsFWHSPBnWYD/o/v4e8Nd4L0m1rFM0PUgrc0uyV2QilLLmSX+vfPE sTow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I/oQJBrzI8ra4O0kLYc3DHwP3f+1ifcyyKJhpThm+/w=; b=Gzy12m+DeqbR80IcLgZfo9c1iaIwcPnSlFv9AOY+vjoZ0HJjsX9nt3wuZzZgKYkLc1 yyOk/i12c76xTsOEm2ebklF26ZXqeSpKQbQE7RCFAnLT/haholvMp86rhkuck9n+MWYz maw7u0aD3A8fwI46Gd0BPeGp794gNBEVB/uaxUb2h+K8+M3/4TwlqOzN1uTVHBM+6W7Q Qu0+kEPho+Qasq5dorIazIBR4f3vA4woRCyRTE/TFDDjXRBc3dyJ8CdG+vRx2c8mrPlQ eXKJqq//QSy80YA1O9NMExnYLiAYzzcmLwViW2dcmnybyenUiQmL0PtNQkl1xaPv1fnt 5Nag== X-Gm-Message-State: AOAM532Xx1SEmHDVlPqtmzu2RG3P7dr3i6+Ekjz8gkHCtC3kXfGB0xtN 6qHk+oUek+Z1TFnutfdtWq37XmY5p/VSO/JeA3g= X-Google-Smtp-Source: ABdhPJxttRUlso0y4VWgqG3xZNeRjC6Ub0dFcaxAqMjrKzCcLwxaKcIB4f45sSk8sN5SyS/MXFBfLPcSSgjJW70Yw04= X-Received: by 2002:a05:6402:1b92:: with SMTP id cc18mr47594349edb.31.1634006004372; Mon, 11 Oct 2021 19:33:24 -0700 (PDT) MIME-Version: 1.0 References: <8cf1ea71-b609-00e8-b8f0-c85ba61b7312@pgmasters.net> <4dbad191-9b40-4bb6-8940-d18f2e93c3ce@www.fastmail.com> <5b9fceed-8f91-467f-a64e-2134c5c3f496@www.fastmail.com> <52edc9d2-8e52-4cde-9a15-991961b78387@www.fastmail.com> <9d5ef845-391a-4c66-b298-0f594d9e6828@www.fastmail.com> <7e4b5c48-a3d3-4b7e-b455-2d50c60a0ab7@www.fastmail.com> <57373e8b-1264-cd37-404e-8edbcf7884cc@enterprisedb.com> <86d76e89-9a96-411a-8077-f8918cbae2e1@www.fastmail.com> <3dbf7241-a417-45c9-9a0e-04a079de9b9f@www.fastmail.com> <0ca5b27f-edf8-4ef9-a9e2-533216890f62@www.fastmail.com> <532a18d8-ce90-4444-8570-8a9fcf09f329@www.fastmail.com> <0c2464d4-65f4-4d91-aeb2-c5584c1350f5@www.fastmail.com> In-Reply-To: From: Ajin Cherian Date: Tue, 12 Oct 2021 13:33:12 +1100 Message-ID: Subject: Re: row filtering for logical replication To: Dilip Kumar Cc: Amit Kapila , 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 Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Oct 12, 2021 at 1:37 AM Dilip Kumar wrote: > > On Wed, Oct 6, 2021 at 2:33 PM Ajin Cherian wrote: > > > > On Sat, Oct 2, 2021 at 5:44 PM Ajin Cherian wrote: > > > > > > I have for now also rebased the patch and merged the first 5 patches > > > into 1, and added my changes for the above into the second patch. > > > > I have split the patches back again, just to be consistent with the > > original state of the patches. Sorry for the inconvenience. > > Thanks for the updated version of the patch, I was looking into the > latest version and I have a few comments. > > > + if ((att->attlen == -1 && > VARATT_IS_EXTERNAL_ONDISK(tmp_new_slot->tts_values[i])) && > + (!old_slot->tts_isnull[i] && > + !(VARATT_IS_EXTERNAL_ONDISK(old_slot->tts_values[i])))) > + { > + tmp_new_slot->tts_values[i] = old_slot->tts_values[i]; > + newtup_changed = true; > + } > > If the attribute is stored EXTERNAL_ONDIS on the new tuple and it is > not null in the old tuple then it must be logged completely in the old > tuple, so instead of checking > !(VARATT_IS_EXTERNAL_ONDISK(old_slot->tts_values[i]), it should be > asserted, > > > + heap_deform_tuple(newtuple, desc, new_slot->tts_values, > new_slot->tts_isnull); > + heap_deform_tuple(oldtuple, desc, old_slot->tts_values, > old_slot->tts_isnull); > + > + if (newtup_changed) > + tmpnewtuple = heap_form_tuple(desc, tmp_new_slot->tts_values, > new_slot->tts_isnull); > + > + old_matched = pgoutput_row_filter(relation, NULL, oldtuple, entry); > + new_matched = pgoutput_row_filter(relation, NULL, > + newtup_changed ? tmpnewtuple : > newtuple, entry); > > I do not like the fact that, first we have deformed the tuples and we > are again using the HeapTuple > for expression evaluation machinery and later the expression > evaluation we do the deform again. > > So why don't you use the deformed tuple as it is to store as a virtual tuple? > > Infact, if newtup_changed is true then you are forming back the tuple > just to get it deformed again > in the expression evaluation. > > I think I have already given this comment on the last version. Right, I only used the deformed tuple later when it was written to the stream. I will modify this as well. regards, Ajin Cherian Fujitsu Australia