On Thu, Nov 4, 2021 at 1:20 AM Mark Dilger <[email protected]> wrote:
>
> > On Nov 1, 2021, at 10:58 AM, Mark Dilger <[email protected]>
> > wrote:
> >
> > ALTER SUBSCRIPTION..[ENABLE | DISABLE] do not synchronously start or stop
> > subscription workers. The ALTER command updates the catalog's subenabled
> > field, but workers only lazily respond to that. Disabling and enabling the
> > subscription as 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 not check for a change in ownership
> the way they checked for other changes, instead only picking up the new
> ownership information when the worker restarted for some other reason. This
> next patch set fixes that. The application of a change record 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.
