Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vugYA-001SqK-1V for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Feb 2026 00:45:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vugY9-00G5vK-0A for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Feb 2026 00:45:17 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vugY8-00G5vA-2Q for pgsql-hackers@lists.postgresql.org; Tue, 24 Feb 2026 00:45:16 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vugY5-00000000sYa-1zpQ for pgsql-hackers@lists.postgresql.org; Tue, 24 Feb 2026 00:45:15 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 61O0j5Af3797861; Mon, 23 Feb 2026 19:45:05 -0500 From: Tom Lane To: Jacob Champion cc: Jelte Fennema-Nio , pgsql-hackers@lists.postgresql.org, Andrew Dunstan Subject: Re: pgsql: libpq: Grease the protocol by default In-reply-to: References: <3626145.1771885089@sss.pgh.pa.us> <3635497.1771889682@sss.pgh.pa.us> Comments: In-reply-to Jacob Champion message dated "Mon, 23 Feb 2026 15:41:46 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3797859.1771893905.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Feb 2026 19:45:05 -0500 Message-ID: <3797860.1771893905@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Jacob Champion writes: > Something like the attached (tested only against 9.2 so far)? I would > plan to backpatch after feature freeze is lifted. This does not fix it for me on a local buildfarm instance. I still get the same failure during 9.2-to-HEAD cross-version upgrade: =3D=3D~_~=3D=3D=3D-=3D-=3D=3D=3D~_~=3D=3D /home/buildfarm/bf-data/fs-upgra= de.tester/HEAD/REL9_2_STABLE-dump1.log =3D=3D~_~=3D=3D=3D-=3D-=3D=3D=3D~_~= =3D=3D pg_dumpall: error: connection to server on socket "/home/buildfarm/bf-data= /tmp/buildfarm-0fIcMg/.s.PGSQL.5700" failed: FATAL: unsupported frontend = protocol 3.9999: server supports 1.0 to 3.0 This indicates a bug in either the server being contacted or a proxy handling the connection. Please consider reporting this to the maintainers of that software. For more information, including instructions on how to work around this issue for now, visit https://www.postgresql.org/docs/devel/libpq-connect.html#L= IBPQ-CONNECT-MAX-PROTOCOL-VERSION It's not obvious to me where the problem lies. I can replicate the failure by trying to use HEAD's psql to connect to a 9.2 server, but adding -d "max_protocol_version=3D3.0" makes psql happy, so why not pg_dumpall? Also: I was initially baffled why you thought this needs back-patching, but I guess you have one eye on packagers like Debian who think they can make older versions use newer libpq.so. It'd be good to spell out that reasoning in the commit message. regards, tom lane