Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Subject: Re: Non-superuser subscription owners
From: Mark Dilger <mark.dilger@enterprisedb.com>
In-Reply-To: 
 <CAA4eK1KWhXNNZoiRLo-BDLhnC7+9XThnkX5JqtTakFvuH=M_5g@mail.gmail.com>
Date: Mon, 29 Nov 2021 08:26:38 -0800
Cc: Jeff Davis <pgsql@j-davis.com>,
 Andrew Dunstan <andrew@dunslane.net>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>,
 Robert Haas <robertmhaas@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BE379596-7B75-41FF-8222-2EC8E4E6CEFC@enterprisedb.com>
References: <9DFC88D3-1300-4DE8-ACBC-4CEF84399A53@enterprisedb.com>
 <c1c334a2-5d85-687f-f0dc-0ac8c422ca1a@dunslane.net>
 <CD02D159-7260-4247-888F-2CFA7AD3798D@enterprisedb.com>
 <6BB4451E-7B1B-474C-BD1F-DB7531E720C6@enterprisedb.com>
 <aa28945f9f348307c8ac833a937b5fca732668b8.camel@j-davis.com>
 <6A2B0FF6-CC86-48CE-B0D3-5401AA5CFEA9@enterprisedb.com>
 <b6f6ed921b6e219875801857204b14bbc8782e5e.camel@j-davis.com>
 <CF56AC0D-7495-4E8D-A48F-FF38BD8074EB@enterprisedb.com>
 <CAA4eK1KHE_xmxk==CqTcTzceC_n00tRWBLm3DGUWhaaPTguz3A@mail.gmail.com>
 <1BB0A553-3FE9-4A91-A975-6F9D8C157FBD@enterprisedb.com>
 <CAA4eK1LBjtqHH2h4TO7FHG=FJRfygfkeEb7AFj-dh6rqg3xqUA@mail.gmail.com>
 <CC5DAC9C-F767-4256-BFEF-32D5A566D254@enterprisedb.com>
 <7C62876F-5D19-4B5C-96AC-5590B10A49B2@enterprisedb.com>
 <66f55a6b9ff7bdd6bfd0d05e8fd8351690e69e23.camel@j-davis.com>
 <FE7D7024-6723-4ACB-82AB-94F6A194BE0D@enterprisedb.com>
 <CAA4eK1KWhXNNZoiRLo-BDLhnC7+9XThnkX5JqtTakFvuH=M_5g@mail.gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/BE379596-7B75-41FF-8222-2EC8E4E6CEFC%40enterprisedb.com>
Precedence: bulk


> On Nov 28, 2021, at 9:56 PM, Amit Kapila <amit.kapila16@gmail.com> =
wrote:
>=20
> In ExecUpdate(), we convert Update to DELETE+INSERT when the
> partition constraint is failed whereas, on the subscriber-side, it
> will simply fail in this case. It is not clear to me how that is
> directly related to this patch but surely it will be a good
> improvement on its own and might help if that requires us to change
> some infrastructure here like hooking into executor at a higher level.

I would rather get a fix for non-superuser subscription owners committed =
than expand the scope of work and have this patch linger until the v16 =
development cycle.  This particular DELETE+INSERT problem sounds =
important but unrelated and out of scope.

> I agree that if we want to do all of this then that would require a
> lot of changes. However, giving an error for RLS-enabled tables might
> also be too restrictive. The few alternatives could be that (a) we
> allow subscription owners to be either have "bypassrls" attribute or
> they could be superusers. (b) don't allow initial table_sync for rls
> enabled tables. (c) evaluate/analyze what is required to allow Copy
> =46rom to start respecting RLS policies. (d) reject replicating any
> changes to tables that have RLS enabled.
>=20
> I see that you are favoring (d) which clearly has merits like lesser
> code/design change but not sure if that is the best way forward or we
> can do something better than that either by following one of (a), (b),
> (c), or something less restrictive than (d).

I was favoring option (d) only when RLS policies exist for one or more =
of the target relations.

Skipping the table_sync step while replicating tables that have RLS =
policies for subscriptions that are owned by users who lack bypassrls is =
interesting.  If we make that work, it will be a more complete solution =
than option (d).

=E2=80=94
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company