Re: Non-superuser subscription owners

> On Dec 9, 2021, at 7:41 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> 
> 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.
>>> 
>>> 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.
>> 
>> I think it would be better to do it before we allow subscription
>> owners to be non-superusers.
> 
> I think it would be better not to ever do it at any time.
> 
> 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?

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company