Re: Non-superuser subscription owners - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Non-superuser subscription owners
Date
Msg-id CAA4eK1JvLmHRc0m_tv5zXZkEGDoEPQKsGgeL+Ois2msGhJ2RAQ@mail.gmail.com
Whole thread Raw
In response to Re: Non-superuser subscription owners  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: Non-superuser subscription owners
List pgsql-hackers
On Thu, Nov 4, 2021 at 1:20 AM Mark Dilger <mark.dilger@enterprisedb.com> wrote:
>
> > On Nov 1, 2021, at 10:58 AM, Mark Dilger <mark.dilger@enterprisedb.com> wrote:
> >
> > ALTER SUBSCRIPTION..[ENABLE | DISABLE] do not synchronously start or stop subscription workers.  The ALTER command
updatesthe catalog's subenabled field, but workers only lazily respond to that.  Disabling and enabling the
subscriptionas part of the OWNER TO would not reliably accomplish anything. 
>
> I have rethought my prior analysis.  The problem in the previous patch was that the subscription apply workers did
notcheck for a change in ownership the way they checked for other changes, instead only picking up the new ownership
informationwhen the worker restarted for some other reason.  This next patch set fixes that.  The application of a
changerecord may continue under the old ownership permissions when a concurrent command changes the ownership of the
subscription,but the worker will pick up the new permissions before applying the next record. 
>

Are you talking about the below change in the above paragraph?

@@ -2912,6 +2941,7 @@ maybe_reread_subscription(void)
  strcmp(newsub->slotname, MySubscription->slotname) != 0 ||
  newsub->binary != MySubscription->binary ||
  newsub->stream != MySubscription->stream ||
+ newsub->owner != MySubscription->owner ||
  !equal(newsub->publications, MySubscription->publications))
  {

If so, I am not sure how it will ensure that we check the ownership
change before applying each change? I think this will be invoked at
each transaction boundary, so, if there is a transaction with a large
number of changes, all the changes will be processed under the
previous owner.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Failed transaction statistics to measure the logical replication progress
Next
From: Masahiko Sawada
Date:
Subject: Re: Skipping logical replication transactions on subscriber side