MIME-Version: 1.0
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>
In-Reply-To: <d87ac2f15c496f78bc6288494d18e39728566c76.camel@j-davis.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Mon, 29 Jun 2026 09:57:54 +0530
Message-ID: 
 <CAA4eK1J7tg+J-vrRkFFqoySXxe5h7K9Qe--2nQcfN3xY8PG0Sw@mail.gmail.com>
Subject: Re: Bug in ALTER SUBSCRIPTION ... SERVER / ... CONNECTION with broken
 old server
To: Jeff Davis <pgsql@j-davis.com>
Cc: Chao Li <li.evan.chao@gmail.com>,
 Zsolt Parragi <zsolt.parragi@percona.com>,
	"Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
 Ajin Cherian <itsajin@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAA4eK1J7tg%2BJ-vrRkFFqoySXxe5h7K9Qe--2nQcfN3xY8PG0Sw%40mail.gmail.com>
Precedence: bulk

On Tue, Jun 23, 2026 at 2:40=E2=80=AFAM Jeff Davis <pgsql@j-davis.com> wrot=
e:
>
> On Fri, 2026-06-19 at 11:40 -0700, Jeff Davis wrote:
> >   * add an escape hatch for users to turn off tablesync slots so that
> > DROP will always succeed
>
> It looks like SLOT_NAME=3DNONE is already supposed to be this escape
> hatch, even for tablesync slots. From the docs:
>
> "To proceed in this situation, first disable the subscription by
> executing ALTER SUBSCRIPTION ... DISABLE, and then disassociate it from
> the replication slot by executing ALTER SUBSCRIPTION ... SET (slot_name
> =3D NONE). After that, DROP SUBSCRIPTION will no longer attempt any
> actions on a remote host."
>
> https://www.postgresql.org/docs/devel/sql-dropsubscription.html
>
> But DropSubscription() only does the early-return if there are no
> tablesync slots. If there are tablesync slots, it still tries to
> contact the publisher, even if SLOT_NAME=3DNONE.
>

AFAICS, the corresponding DropSubscription() code is as follows:

if (!slotname && rstates =3D=3D NIL)
{
table_close(rel, NoLock);
return;
}
....
if (OidIsValid(subserver))
conninfo =3D construct_subserver_conninfo(subserver, subowner, &err);
else
conninfo =3D subconninfo;

if (conninfo)
wrconn =3D walrcv_connect(conninfo, true, true, must_use_password,
subname, &err);

if (wrconn =3D=3D NULL)
{
if (!slotname)
{
/* be tidy */
list_free(rstates);
table_close(rel, NoLock);
return;
}
else
{
ReportSlotConnectionError(rstates, subid, slotname, err);
}
}

So, if the connection is not successful then we simply return without
checking tablesync slots (when slotname is NONE) whereas with FDW
server connection, the ERROR will be raised from
construct_subserver_conninfo->ForeignServerConnectionString(). Isn't
that different from current situation?

> >   * consider it an unimportant edge case and leave it the way it is
> > (with 0001 & 0002 already done), and close the open item
>
> I plan to close this open item, and treat the above as a pre-existing
> bug, which may require a backport.
>

As per my understanding it is better to go with your fix idea even
though we don't have better ideas for HINT message. I see your point
of making HINT much longer as we may need to add something like (...
or re-create the user mapping/ACL and retry..), so we can keep the
current one as it is and if we see any real user complaint then we can
consider improving it in the future.

--=20
With Regards,
Amit Kapila.