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: 
 <CA+Tgmob7OUFa0-1NS3tDrbyR+VmvmcWWw8qd61=aDQ7nn6suyA@mail.gmail.com>
Date: Thu, 9 Dec 2021 09:22:07 -0800
Cc: Amit Kapila <amit.kapila16@gmail.com>,
 Jeff Davis <pgsql@j-davis.com>,
 Andrew Dunstan <andrew@dunslane.net>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7C8B9FA7-FECA-4C1C-9D0D-FCFE68C93EC3@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>
 <CAA4eK1KnEptxtJTzo9LNb2VgRBYcBWxY+NSx2hJR8iUM8JXktw@mail.gmail.com>
 <18b267939a9d1ae27e9b3643d53395f4e29ea6ce.camel@j-davis.com>
 <CAA4eK1K1=DbXCNfA32urxZga6YxeiCvcTHvJu-+BtLCtVgqJ2w@mail.gmail.com>
 <785e8b8ab06f123cf754862557bd3171aeba4d65.camel@j-davis.com>
 <CAA4eK1JJsBzJsStA_LYrJu0WmOG+tWXcS9G4mY1G4CsQVBcaQw@mail.gmail.com>
 <CA+Tgmob7OUFa0-1NS3tDrbyR+VmvmcWWw8qd61=aDQ7nn6suyA@mail.gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/7C8B9FA7-FECA-4C1C-9D0D-FCFE68C93EC3%40enterprisedb.com>
Precedence: bulk


> On Dec 9, 2021, at 7:41 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>=20
> On Tue, Nov 30, 2021 at 6:55 AM Amit Kapila <amit.kapila16@gmail.com> =
wrote:
>>> This patch does detect ownership changes more quickly (at the
>>> transaction boundary) than the current code (only when it reloads =
for
>>> some other reason). Transaction boundary seems like a reasonable =
time
>>> to detect the change to me.
>>>=20
>>> Detecting faster might be nice, but I don't have a strong opinion =
about
>>> it and I don't see why it necessarily needs to happen before this =
patch
>>> goes in.
>>=20
>> I think it would be better to do it before we allow subscription
>> owners to be non-superusers.
>=20
> I think it would be better not to ever do it at any time.
>=20
> It seems like a really bad idea to me to change the run-as user in the
> middle of a transaction.

I agree.  We allow SET ROLE inside transactions, but faking one on the =
subscriber seems odd.  No such role change was performed on the =
publisher side, nor is there a principled reason for assuming the old =
run-as role has membership in the new run-as role, so we'd be pretending =
to do something that might otherwise be impossible.

There was some discussion off-list about having the apply worker take =
out a lock on its subscription, thereby blocking ownership changes =
mid-transaction.  I coded that and it seems to work fine, but I have a =
hard time seeing how the lock traffic would be worth expending.  Between =
(a) changing roles mid-transaction, and (b) locking the subscription for =
each transaction, I'd prefer to do neither, but (b) seems far better =
than (a).  Thoughts?

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