Re: Bug in ALTER SUBSCRIPTION ... SERVER / ... CONNECTION with broken old server

On Tue, Jun 23, 2026 at 2:40 AM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>
> 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=NONE 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
> = 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=NONE.
>

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

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

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

if (wrconn == 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.

--
With Regards,
Amit Kapila.