> 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
performedon the publisher side, nor is there a principled reason for assuming the old run-as role has membership in the
newrun-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
ownershipchanges mid-transaction. I coded that and it seems to work fine, but I have a hard time seeing how the lock
trafficwould 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