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 1nSNOb-00040N-BT for pgsql-hackers@arkaria.postgresql.org; Thu, 10 Mar 2022 18:20:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nSNOa-0002H2-6o for pgsql-hackers@arkaria.postgresql.org; Thu, 10 Mar 2022 18:20:16 +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 1nSNOZ-0002Gt-Tr for pgsql-hackers@lists.postgresql.org; Thu, 10 Mar 2022 18:20:15 +0000 Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nSNOX-0002xm-Eq for pgsql-hackers@postgresql.org; Thu, 10 Mar 2022 18:20:14 +0000 Received: by mail-ej1-x62c.google.com with SMTP id gb39so13910945ejc.1 for ; Thu, 10 Mar 2022 10:20:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=3xcbJerglBGAjZ9UTBkguLy8AlDrEp0T/d2cNazU918=; b=AAFZ8omdk3p6pheqPO8YC1ktREcKznyQipKNHgeBqXdMJMfSygXK3a4cgisC/IpkUW On+UV6pHpyQ8dVXdv4q5CP8UyI553ggUPfZc6zOjsMzzi0G2hTksxdopkK9weJXQmYl9 1bp80mPlLA49EE2iMCEWP6EChTsrO7qdFCGihXhtOtKDkG0zVcqERRA7kmwS9ptKwY0y JTN45T7CAJ5gzGsdjC9JM7gMRBqETbviaMr+3S20/voWpSMaN+BhVzGnc6TKyv2IXyUL KcTcuPBC7K6gKVsu0MbvdMQASw7nQS9BvuDk5d6z18zpz9gVrGtRLHkWgQ4494puMPzX Do4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=3xcbJerglBGAjZ9UTBkguLy8AlDrEp0T/d2cNazU918=; b=GelRct28Qhak56wYecLcKPNKGcbZmc629mjsyrQdoBkY5hkKmoNFJ3vQESNdtzOADl ieIE0ZsbTOTz1tvxRt4lh/Wck4RWNVWxutrGLmP1Sl2NdQKTfif1/kBNiGEsDk+V9TW3 TyjEvIl0NsvJ5Skom5J1A1LA3v5HeD+PWspvDPGg6dG4RNMl7NLkaXwbSubiMInmMvLL Mk7j1vtlXd066n6IaP47iY41UB3mwaMoGKFld7D93jNNdVycZ2OfbdSGhIMZGTL4frHu 6MLvad5PLoIEr+QkQdx3LVNUeVYpzGA6dz0cOBXbifohfhOP/FeSRpXibpecW5wRDWYD 8SLQ== X-Gm-Message-State: AOAM531Lf414Z7YupxPnsrBypgX0N3jWMoh3b5RjpXPwhJqnT/Z0GCjr uyIZ+F+H4o43NuW9jKw2XxHGofSbwlrD0sm31AP7xRudUtIrysvvx7Tkf1nBkW+r4BCic+jtcut 0n53xvX7C0eNC00NvJUNcs8qBYNxJ4NjDT5JpO0h3BVFfif4mCmbfP7bAWbLRG0pN9uto3w4HsX sxou5JwhpgQrlmdTXl1hwu772Rda6GwhvSTziu X-Google-Smtp-Source: ABdhPJxJoKHpCPAI6VMjxpykC9jBVb/iasZ+3z0U4BZrK1+1F/V+GPeGNoxfPinCHjfk1rmDOQvOTQ== X-Received: by 2002:a17:906:5c4:b0:6cd:8d9c:3c7d with SMTP id t4-20020a17090605c400b006cd8d9c3c7dmr5506604ejt.554.1646936411944; Thu, 10 Mar 2022 10:20:11 -0800 (PST) Received: from [10.137.0.18] (static-84-42-175-93.net.upcbroadband.cz. [84.42.175.93]) by smtp.gmail.com with ESMTPSA id y18-20020aa7ca12000000b0041677910461sm2321554eds.53.2022.03.10.10.20.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Mar 2022 10:20:11 -0800 (PST) Message-ID: <1269d2ac-d321-699b-e354-c0dfec6a7745@enterprisedb.com> Date: Thu, 10 Mar 2022 19:20:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: Column Filtering in Logical Replication Content-Language: en-US To: Peter Eisentraut , Amit Kapila Cc: Alvaro Herrera , Justin Pryzby , "houzj.fnst@fujitsu.com" , Rahila Syed , Peter Smith , pgsql-hackers , shiy.fnst@fujitsu.com References: <202201120041.p24wvsfcsope@alvherre.pgsql> From: Tomas Vondra In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CLOUD-SEC-AV-Info: enterprisedb,google_mail,monitor X-CLOUD-SEC-AV-Sent: true X-Gm-Spam: 0 X-Gm-Phishy: 0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 3/9/22 10:20, Peter Eisentraut wrote: > > On 07.03.22 16:18, Tomas Vondra wrote: >> AFAICS these issues should be resolved by the adoption of the row-filter >> approach (i.e. it should fail the same way as for row filter). > > The first two patches (additional testing for row filtering feature) > look okay to me. > > Attached is a fixup patch for your main feature patch (the third one). > > It's a bit of code and documentation cleanup, but mainly I removed the > term "column filter" from the patch.  Half the code was using "column > list" or similar and half the code "column filter", which was confusing. >  Also, there seemed to be a bit of copy-and-pasting from row-filter code > going on, with some code comments not quite sensible, so I rewrote some > of them.  Also some code used "rf" and "cf" symbols which were a bit > hard to tell apart.  A few more letters can increase readability. > > Note in publicationcmds.c OpenTableList() the wrong if condition was used. > Thanks, I've merged these changes into the patch. > I'm still confused about the intended replica identity handling.  This > patch still checks whether the column list contains the replica identity > at DDL time.  And then it also checks at execution time.  I thought the > latest understanding was that the DDL-time checking would be removed.  I > think it's basically useless now, since as the test cases show, you can > subvert those checks by altering the replica identity later. Are you sure? Which part of the patch does that? AFAICS we only do those checks in CheckCmdReplicaIdentity now, but maybe I'm missing something. Are you sure you're not looking at some older patch version? regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company