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 1wL76q-001XS2-1F for pgsql-hackers@arkaria.postgresql.org; Thu, 07 May 2026 22:22:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wL76o-006Ydf-0J for pgsql-hackers@arkaria.postgresql.org; Thu, 07 May 2026 22:22:18 +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 1wL76n-006YdQ-26 for pgsql-hackers@lists.postgresql.org; Thu, 07 May 2026 22:22:17 +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 1wL76k-00000000i2u-2S1l for pgsql-hackers@lists.postgresql.org; Thu, 07 May 2026 22:22:16 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.18.1/8.18.1) with ESMTP id 647MMEr0898415; Thu, 7 May 2026 18:22:14 -0400 From: Tom Lane To: Michael Paquier cc: Daniel Gustafsson , PostgreSQL-development Subject: Re: PostgreSQL and OpenSSL 4.0.0 In-reply-to: References: <066B07BB-85FA-487C-BE8C-40F791CFC3C4@yesql.se> <65C5DC15-DE27-4D36-8AEE-A854C23B3834@yesql.se> Comments: In-reply-to Michael Paquier message dated "Fri, 08 May 2026 07:13:05 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <898413.1778192534.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Thu, 07 May 2026 18:22:14 -0400 Message-ID: <898414.1778192534@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Michael Paquier writes: > On Thu, May 07, 2026 at 03:44:45PM +0200, Daniel Gustafsson wrote: >> For 14 through master the attached compiles without warnings and tests = green on >> all the supported versions of OpenSSL and LibreSSL. That being said, I= 'm not >> sure that we want to go all the way to 14 since if something does break= , we >> can't really go around fixing it - I think amending the docs in 14 stat= ing that >> OpenSSL 3.6 is the highest supported version is a better solution. > One issue with this approach is that any builds on these branches (say > REL_14_STABLE + OpenSSL 1.0.1) would be forced to either upgrade > OpenSSL to at least 3.6 for a minor Postgres update or give up on any > fix we can put on the 14 stable branch for six more months. None of > these solutions are cool. With one eye on the calendar, I think the right way to proceed is to push this to all branches (including 14) soon after next week's releases. I feel this is too high-risk to shove in just before a release, but shortly after one is ideal since we'll have 3 months to find out any problems. I would support omitting 14 if we were down to just one remaining release for it, but we'll have 2 (August and November). So there will still be an opportunity to fix things if there's an issue that manages to escape notice until after the August releases. regards, tom lane