Message-ID: <ff36d1ab77de76fb844b7005b8dc6a9e2b43c293.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>, Chao Li <li.evan.chao@gmail.com>
Cc: Zsolt Parragi <zsolt.parragi@percona.com>, "Hayato Kuroda (Fujitsu)"
	 <kuroda.hayato@fujitsu.com>, Ajin Cherian <itsajin@gmail.com>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: Fri, 19 Jun 2026 11:40:34 -0700
In-Reply-To: <5c629d2455946ad2fde3c184f64ea2c323ef2133.camel@j-davis.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>
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/ff36d1ab77de76fb844b7005b8dc6a9e2b43c293.camel%40j-davis.com>
Precedence: bulk

On Wed, 2026-06-17 at 16:10 -0700, Jeff Davis wrote:
> v7-0003 is more than just an error message change, so I updated the
> commit message. It handles the case where the drop path has
> rstates!=3DNIL but slot_name=3DNONE: without 0003, the drop will fail
> while
> trying to construct the conninfo (without the HINT); with 0003, the
> drop will silently succeed without removing the tablesync slots (as
> it
> does with a connection failure when subconninfo is set).
>=20
> If the use of a subtransaction is fine there, then I think we should
> proceed with 0003 and whatever hint message is agreeable.

0002 committed.

For 0003, I don't think we can absorb every kind of error that might
happen inside fdwconnection. libpqrcv_connect() doesn't attempt to do
so, so neither should construct_subserver_conninfo().

What 0003 is really trying to avoid is fairly normal kinds of errors
that can happen on a non-broken FDW that get in the way of dropping a
subscription. That includes a missing user mapping or a failed ACL
check. But aside from that, it's hard to think of other examples we'd
clearly want to absorb.

Options:

  * check for those two error codes explicitly
  * try to be more systematic about what kinds of errors should be
absorbed or not
  * add an escape hatch for users to turn off tablesync slots so that
DROP will always succeed
  * consider it an unimportant edge case and leave it the way it is
(with 0001 & 0002 already done), and close the open item

Thoughts?

Regards,
	Jeff Davis