Message-ID: <8185e4371a3b2f4590ec18246cec473363b35700.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>
Cc: Chao Li <li.evan.chao@gmail.com>, 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: Mon, 06 Jul 2026 16:46:10 -0700
In-Reply-To: 
 <CAA4eK1J7tg+J-vrRkFFqoySXxe5h7K9Qe--2nQcfN3xY8PG0Sw@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>
	 <CAA4eK1J7tg+J-vrRkFFqoySXxe5h7K9Qe--2nQcfN3xY8PG0Sw@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/8185e4371a3b2f4590ec18246cec473363b35700.camel%40j-davis.com>
Precedence: bulk

On Mon, 2026-06-29 at 09:57 +0530, Amit Kapila wrote:
> wrconn =3D walrcv_connect(conninfo, true, true, must_use_password,
> subname, &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?

It's easier to cause an error in ForeignServerConnectionString(); but
walrcv_connect() can throw errors, too. Also, a network connection is a
side-effect that you may not want to have for whatever reason.

I think it's better to have an escape that prevents any connection to
the publisher, as the documentation says, to deal with these kinds of
edge cases.

Regards,
	Jeff Davis