public inbox for [email protected]  

help / color / mirror / Atom feed

From: Mark Dilger <[email protected]>
To: Amit Kapila <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Cc: Robert Haas <[email protected]>
Subject: Re: Non-superuser subscription owners
Date: Thu, 18 Nov 2021 07:45:13 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAA4eK1JvLmHRc0m_tv5zXZkEGDoEPQKsGgeL+Ois2msGhJ2RAQ@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAA4eK1JvLmHRc0m_tv5zXZkEGDoEPQKsGgeL+Ois2msGhJ2RAQ@mail.gmail.com>



> On Nov 18, 2021, at 3:37 AM, Amit Kapila <[email protected]> wrote:
> 
>> 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.

Yes, your analysis appears correct.  I was sloppy to say "before applying the next record".  It will pick up the change before applying the next transaction.

The prior version of the patch only picked up the change if it happened to start a new worker, but could process multiple transactions without noticing the change.  Now, it is limited to finishing the current transaction.  Would you prefer that the worker noticed the change in ownership and aborted the transaction on the subscriber side?  Or should the ALTER SUBSCRIPTION..OWNER TO block?  I don't see much advantage to either of those options, but I also don't think I have any knock-down argument for my approach either.  What do you think?

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

view thread (68+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Non-superuser subscription owners
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox