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 1nlavw-0003LL-EX for pgsql-hackers@arkaria.postgresql.org; Mon, 02 May 2022 18:38:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nlavu-000627-Vf for pgsql-hackers@arkaria.postgresql.org; Mon, 02 May 2022 18:38:06 +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 1nlavu-00060q-6D for pgsql-hackers@lists.postgresql.org; Mon, 02 May 2022 18:38:06 +0000 Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nlavr-00013l-MI for pgsql-hackers@lists.postgresql.org; Mon, 02 May 2022 18:38:04 +0000 Received: by mail-ed1-x52a.google.com with SMTP id z99so17575369ede.5 for ; Mon, 02 May 2022 11:38:03 -0700 (PDT) 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=JehDnNtYd64fxyJ+OG00liriRwgLdWyrcDkei1ebGkw=; b=KOHu0pMakuYWRoTUwAHfPhJYFpBtCf4tKyJye5DMDCGxsF0M4zRcD2V/LwUnxqIeGW ZyGbA7ioaL/jjM/dr0tq24UEKKbCQrbelJjIW5N8YP4kI1eFMJ4/onaQt0OIld+eNL7t qefRfE7DOZTMgFFZyObnMghB+8qhoHoxo//9myMXFyRfY4jiWGq+7npdOLbyrChhNaVe Clv9sLQ2h19o7YUR+RX2MgMb32t8ZX6fzqdLlgNrQQRhEjexP9wT76GAk5pDqPpUJ7jk ckOXNsLX6IWXHmflhBKUwphklCzXpFf05eLiyxWXHdbRHEy/lr0r5+iTaQDsEtf61htP uw9A== 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=JehDnNtYd64fxyJ+OG00liriRwgLdWyrcDkei1ebGkw=; b=OLMDNto/zdAnDB1GDO3SpqpDlGAs7Kmsn4vaetge5WNNE8yGxK7wVyOX3hhF6fP8fu 1+LlgP0bCtpTP+y8frKUy4orDWnyHpA7RhHD2s8KrqIFStDFuIwItmDsTIcb8OiF2ALg Djj5iq3J96O1dSr/xxOVk7Y0JoCycHlbfK9lyCUYuwyus0cWvUkhmFUH6VRJ01wbKovw ApSZ1nh4GsyhyaynIDCE9dg9ZJnLkdaDNEdkty0uY2u69wqv009Yxz8ASL/RdlbphyQ/ Al+uoog6X8b2C9+PDdoOwvvVc20WVWyMRtjY0dbNG1vOPAFHb09ypfBwwjBHxhWgDuxi DIpw== X-Gm-Message-State: AOAM5320o1ZhA/lToqxuA23AEL8xtVcY9teETR9Cj49jo/T+f7a4+icr +asqDNTq/yUqyNgkq/gEOGBHaCC/aihm8NXFH+yG9IJe4FhY2Bq6X3+4XHaQ3IlLh6QLdZw6ltg uCj8CRAdA/GZrEa7AjHN5CTBlQK0E9L/Sz3t/nTNw54uQCG6HCRxeniHZWIrGdXNw55TPMpcVMZ nHsPiDGaTpHg8cH1BxRpnQ7eTDWk+l6Ge/aVcV+z8Xd16cyF8ClMHC X-Google-Smtp-Source: ABdhPJzXvW6+U62hIsnZuVnollkBhYGzPgGd6JrffUMShvQwXzq1Zd1zE7KXTPQXlbVpYMahviLRug== X-Received: by 2002:a05:6402:703:b0:426:110e:5d22 with SMTP id w3-20020a056402070300b00426110e5d22mr14658558edx.375.1651516681678; Mon, 02 May 2022 11:38:01 -0700 (PDT) Received: from [10.137.0.17] (ip-86-49-250-165.net.upcbroadband.cz. [86.49.250.165]) by smtp.gmail.com with ESMTPSA id gz26-20020a170907a05a00b006f3ef214dd7sm3794923ejc.61.2022.05.02.11.38.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 May 2022 11:38:00 -0700 (PDT) Message-ID: <7fbca40e-b6d0-cd03-e2fc-1338994a8360@enterprisedb.com> Date: Mon, 2 May 2022 20:37:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: bogus: logical replication rows/cols combinations Content-Language: en-US To: Amit Kapila Cc: Alvaro Herrera , Peter Eisentraut , Pg Hackers References: <202204300931.um766ighsghq@alvherre.pgsql> <7fdf7ac3-912b-f450-f9c1-aa239df4ac1a@enterprisedb.com> From: Tomas Vondra In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 5/2/22 13:23, Amit Kapila wrote: > On Mon, May 2, 2022 at 3:05 PM Tomas Vondra > wrote: >> >> On 5/2/22 07:31, Amit Kapila wrote: >>> On Mon, May 2, 2022 at 3:27 AM Tomas Vondra >>> wrote: >>>> >> >>>> The second option has the annoying consequence that it makes this >>>> useless for the "data redaction" use case I described in [2], because >>>> that relies on combining multiple publications. >>>> >>> >>> True, but as a workaround users can create different subscriptions for >>> different publications. >>> >> >> Won't that replicate duplicate data, when the row filters re not >> mutually exclusive? >> > > True, but this is a recommendation for mutually exclusive data, and as > far as I can understand the example given by you [1] and Alvaro has > mutually exclusive conditions. In your example, one of the > publications has a condition (region = 'USA') and the other > publication has a condition (region != 'USA'), so will there be a > problem in using different subscriptions for such cases? > I kept that example intentionally simple, but I'm sure we could come up with more complex use cases. Following the "data redaction" idea, we could also apply the "deny all" approach, and do something like this: -- replicate the minimal column list by default (replica identity) CREATE PUBLICATION p1 FOR TABLE t (id, region); -- replicate more columns for the selected region CREATE PUBLICATION p2 FOR TABLE t (...) WHERE (region = 'USA') Now, I admit this is something I just made up, but I think it seems like a pretty common approach. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company