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

On Tue, Jul 7, 2026 at 5:11 AM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>
> On Mon, 2026-06-29 at 10:07 +0530, Amit Kapila wrote:
> > On Wed, Jun 24, 2026 at 7:48 AM Hayato Kuroda (Fujitsu)
> > <kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
> > >
> > > I went through the 0003 patch. Apart from HINT message, I found
> > > that error code
> > > ERRCODE_CONNECTION_FAILURE is always used. Should we report the
> > > original errcode
> > > of the root cause?
> > >
> >
> > That could be marginally better but not sure if it is worth the
> > complexity. I have a few more points regarding 0003:
> > * Regarding the point: "we can't absorb every kind of error." In the
> > PG_CATCH, re-throw query-cancel / interrupt-class conditions (if
> > those
> > are possible) instead of swallowing them, otherwise a SIGINT during
> > ForeignServerConnectionString() becomes a silent successful DROP (for
> > slot_name=NONE) or a mislabeled connection error.
>
> The DROP SUBSCRIPTION documentation says that:
>
> "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."
>
> But that stopped being true after commit ce0fdbfe97. There should be
> some kind of escape such that we can force a DROP SUBSCRIPTION to
> succeed without trying to connect to the remote host. And if we have
> that escape, then we don't need to overcomplicate this by using a
> subtransaction and trying to guess which errors are recoverable or not.
>

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=NONE? 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. Actually, this best-case try to connect to
publisher works for such cases. I think this is mostly a theoretical
scenario because ideally these tablesync slots should be removed at
the end of tablesync especially when users are doing drop subscription
as part of planned operation, so we can as well rely on the document
as we are doing now.

--
With Regards,
Amit Kapila.