Message-ID: <2ff2a391adc2e86d82803a5f729f42f13448faa1.camel@j-davis.com>
Subject: Re: Bug in ALTER SUBSCRIPTION ... SERVER / ... CONNECTION with
 broken old server
From: Jeff Davis <pgsql@j-davis.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Chao Li
 <li.evan.chao@gmail.com>, Zsolt Parragi <zsolt.parragi@percona.com>, Ajin
 Cherian <itsajin@gmail.com>, PostgreSQL-development
 <pgsql-hackers@postgresql.org>
Date: Wed, 08 Jul 2026 12:20:45 -0700
In-Reply-To: 
 <CAA4eK1KGixKGG9++zZ8BFGp+indVxaof_8DR=9hVrY8=a8erRg@mail.gmail.com>
References: <D908370F-2695-4231-851D-17179A6A6F2A@gmail.com>
	 <CAFPTHDZk-eY1K6OGWhLSWJ0C7qncVQvaxUmBL2r69_1CiznfTA@mail.gmail.com>
	 <960DD2C4-A22C-463A-90ED-86E0FABD8D20@gmail.com>
	 <CAN4CZFMemmQaxs9qT8MW3u_xRXrOa9mtmyup3Nizwb0V_C1axw@mail.gmail.com>
	 <8B38AFCA-7FFA-44CF-B9A8-81BDCEAFB224@gmail.com>
	 <b03eb0fecb7df88cd3eb2acf48bd1230e28a2923.camel@j-davis.com>
	 <705148C3-519C-45E7-9EA8-48D9F3B79B06@gmail.com>
	 <f13a8e29410bbbf9999290f2c04513a8884fa51c.camel@j-davis.com>
	 <1B3A7FF0-3292-484F-992C-27D172772EB8@gmail.com>
	 <65166eb6feb87356f8d60bfe646289ce15a6c729.camel@j-davis.com>
	 <24C6472D-DCAB-4F69-AE8A-FFB4AAB3F6F0@gmail.com>
	 <CAA4eK1+TQXHR50rtp6eKt1Ejj3ttCKoJj9R+tO_0M+mUi0U66A@mail.gmail.com>
	 <5c629d2455946ad2fde3c184f64ea2c323ef2133.camel@j-davis.com>
	 <ff36d1ab77de76fb844b7005b8dc6a9e2b43c293.camel@j-davis.com>
	 <d87ac2f15c496f78bc6288494d18e39728566c76.camel@j-davis.com>
	 <OS9PR01MB12149873B1F63BDBB3E5012CAF5ED2@OS9PR01MB12149.jpnprd01.prod.outlook.com>
	 <CAA4eK1KW5vVQ29RXYagpUb5K8xP-PCKsOXD2spK4j7byrjed-g@mail.gmail.com>
	 <131c80088565c68e64c02572a800316c6bbb379f.camel@j-davis.com>
	 <CAA4eK1KGixKGG9++zZ8BFGp+indVxaof_8DR=9hVrY8=a8erRg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.52.3-0ubuntu1.1 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/2ff2a391adc2e86d82803a5f729f42f13448faa1.camel%40j-davis.com>
Precedence: bulk

On Wed, 2026-07-08 at 10:29 +0530, Amit Kapila wrote:
> Okay, I see your point and we can make it return early when slot_name
> is NONE. However, do we need to consider a case where users want to
> manually manage the subscription's main slot, so it uses
> slot_name=3DNONE? I mean users want to manually maintain the lifecycle
> of the slot and due to that even during the CREATE SUBSCRIPTION, it
> uses the specified slot_name instead of the default. But still
> tablesync slots need to be removed in such a case as those are
> internally created.

The problem is that we are overloading slot_name=3DNONE, and as you point
out, it can mean multiple things.

Can we just have DROP SUBSCRIPTION ... FORCE or DROP SUBSCRIPTION ...
NOCONNECT? That allows the user to clearly express their intent at the
time of the drop, rather than guessing from the state of the
subscription.

If it's too late to do that for 19, we should probably just make the
code match the documentation and don't try to connect if
slot_name=3DNONE. In most ordinary cases that would not cause a problem,
you'd have to have slot_name=3DNONE and also drop the subscription before
the table syncs finish.

Regards,
	Jeff Davis