Message-ID: <3c9b220207b8895086887addd37d371ccd1b420b.camel@j-davis.com>
Subject: Re: Non-superuser subscription owners
From: Jeff Davis <pgsql@j-davis.com>
To: Mark Dilger <mark.dilger@enterprisedb.com>, Andrew Dunstan
	 <andrew@dunslane.net>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: Tue, 16 Nov 2021 10:08:06 -0800
In-Reply-To: <CD02D159-7260-4247-888F-2CFA7AD3798D@enterprisedb.com>
References: <9DFC88D3-1300-4DE8-ACBC-4CEF84399A53@enterprisedb.com>
	 <c1c334a2-5d85-687f-f0dc-0ac8c422ca1a@dunslane.net>
	 <CD02D159-7260-4247-888F-2CFA7AD3798D@enterprisedb.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/3c9b220207b8895086887addd37d371ccd1b420b.camel%40j-davis.com>
Precedence: bulk

On Mon, 2021-11-01 at 10:58 -0700, Mark Dilger wrote:
> It is unclear that I can make ALTER SUBSCRIPTION..OWNER TO
> synchronous without redesigning the way workers respond to
> pg_subscription catalog updates generally.  That may be a good
> project to eventually tackle, but I don't see that it is more
> important to close the race condition in an OWNER TO than for a
> DISABLE.
> 
> Thoughts?

What if we just say that OWNER TO must be done by a superuser, changing
from one superuser to another, just like today? That would preserve
backwards compatibility, but people with non-superuser subscriptions
would need to drop/recreate them.

When we eventually do tackle the problem, we can lift the restriction.

Regards,
	Jeff Davis