On Mon, 2026-06-29 at 10:07 +0530, Amit Kapila wrote:
> On Wed, Jun 24, 2026 at 7:48 AM Hayato Kuroda (Fujitsu)
> <[email protected]> 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.
Regards,
Jeff Davis
