Message-ID: <131c80088565c68e64c02572a800316c6bbb379f.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>, "Hayato Kuroda (Fujitsu)"
	 <kuroda.hayato@fujitsu.com>
Cc: 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: Mon, 06 Jul 2026 16:41:34 -0700
In-Reply-To: 
 <CAA4eK1KW5vVQ29RXYagpUb5K8xP-PCKsOXD2spK4j7byrjed-g@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>
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/131c80088565c68e64c02572a800316c6bbb379f.camel%40j-davis.com>
Precedence: bulk

On Mon, 2026-06-29 at 10:07 +0530, Amit Kapila wrote:
> On Wed, Jun 24, 2026 at 7:48=E2=80=AFAM Hayato Kuroda (Fujitsu)
> <kuroda.hayato@fujitsu.com> wrote:
> >=20
> > 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?
> >=20
>=20
> 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=3DNONE) 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
=3D 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