Thread

PG20 Minimum Dependency Thread

Jacob Champion <jacob.champion@enterprisedb.com> — 2026-06-18T20:01:47Z

...because I don't see one yet, and upcoming things like the Python
test port are going to need clarity in advance, and I wanna stir up
trouble right before I go eat lunch.

= Background =

The most recent (mailing list) discussions I am aware of are at

[1] https://postgr.es/m/16098.1745079444%40sss.pgh.pa.us (Python)
[2] https://postgr.es/m/42e13eb0-862a-441e-8d84-4f0fd5f6def0%40eisentraut.org
(Meson)

The discussion in [2] ended with a growing consensus that we need _a_
policy, and Andres proposed a framework of one, but I don't think one
was actually chosen. (If I missed that somewhere on the list, or at an
in-person meeting, I apologize. Most of this email is moot if that's
the case.)

The partial list of dependency versions for PG19 is here, and if you
know what's pinning one of the blank rows, please consider filling it
in:

     https://wiki.postgresql.org/wiki/Minimum_Dependency_Versions

But I intend this thread to be about PG20, which will release next
year (2027) and will presumably be supported until 2032.

= My Votes =

For PG20, I want to drop support for RHEL 8 (and prior -- we still
have CentOS 7 machines testing HEAD in the buildfarm).

For me, the most important reason is OpenSSL, because upstream has
already reached 4.0 and we still can't drop code written for 1.1.1. An
additional reason is Python 3.6, which was EOL in 2021; I'd like to
avoid pinning that for another six(!) years. It looks like ninja/meson
get a boost too.

RHEL 8 users in the paid Maintenance Support window (ending 2029) will
still be able to use PG19 for its entire lifetime. And the maintenance
window for RHEL 7 is long gone. People can update their machines if
they want shiny new features.

Cherry-picking from Tom's email on the topic in [2], which may not be
representative of his opinion today:

> Maybe we could compromise on
>
>   If the expected PG major version release date is more than N years
>   after the end of full support for an LTS distribution, that OS
>   version does not need to be supported.
>
> Defining it relative to "full support" also reduces questions about
> whether extended support means the same thing to every LTS vendor.
>
> If we set N=2 then we could drop RHEL8 support in PG 19; if we
> set N=3 then it'd be PG 20 (measuring from end of full support
> in May 2024).  I'd be okay with either outcome.

I propose that we adopt N=2. I think we should have stopped supporting
RHEL8 this year (our yum repos won't be shipping PG19 builds for
RHEL8). But I won't complain if consensus forms on N=3; I think it's
just important that we arrive at some agreement on getting rid of RHEL
8.

--Jacob

Re: PG20 Minimum Dependency Thread

Daniel Gustafsson <daniel@yesql.se> — 2026-06-18T21:05:53Z

> On 18 Jun 2026, at 22:01, Jacob Champion <jacob.champion@enterprisedb.com> wrote:

> For me, the most important reason is OpenSSL, because upstream has
> already reached 4.0 and we still can't drop code written for 1.1.1.

The entire OpenSSL 3.x line will be down to just 3.5 LTS by the time we ship
v20.

One complicating factor when it comes to OpenSSL is that we need the 1.1.1 API
support in order to keep LibreSSL supported.  I have a patch almost done for
separating the two such that we can move them independently of each other, but
summer vacation and other $life stuff delayed it.  I'll try to get it posted
shortly so that we can start the discussion around that. 

--
Daniel Gustafsson

Re: PG20 Minimum Dependency Thread

Tom Lane <tgl@sss.pgh.pa.us> — 2026-06-18T21:22:25Z

Jacob Champion <jacob.champion@enterprisedb.com> writes:
> The most recent (mailing list) discussions I am aware of are at
> [1] https://postgr.es/m/16098.1745079444%40sss.pgh.pa.us (Python)
> [2] https://postgr.es/m/42e13eb0-862a-441e-8d84-4f0fd5f6def0%40eisentraut.org
> (Meson)

> The discussion in [2] ended with a growing consensus that we need _a_
> policy, and Andres proposed a framework of one, but I don't think one
> was actually chosen. (If I missed that somewhere on the list, or at an
> in-person meeting, I apologize. Most of this email is moot if that's
> the case.)

FWIW, my impression of that thread was that we had agreed on pretty
much everything except the value of N; if there was some later meeting
that discussed it further, I wasn't there.  Concretely, Andres said:

>> I think we should have a policy roughly along these lines:
>> 1) We don't remove support for OS versions unless they block something
>> 2) We don't remove support for OS versions in minor releases
>> 3) If support for an old OS version makes something harder, it can be removed,
>>    if and only if the OS is older than $age_criteria.
>> 4) As an alternative to removing OS support via 3), somebody desiring
>>    continued support for an older OS version can instead do the work to
>>    develop an alternative to removal of support within $reasonable_timeframe

and we later agreed on my wording for $age_criteria:

>> If the expected PG major version release date is more than N years
>> after the end of full support for an LTS distribution, that OS
>> version does not need to be supported.
>> Defining it relative to "full support" also reduces questions about
>> whether extended support means the same thing to every LTS vendor.
>> If we set N=2 then we could drop RHEL8 support in PG 19; if we
>> set N=3 then it'd be PG 20 (measuring from end of full support
>> in May 2024).  I'd be okay with either outcome.

(hmm, I guess we didn't fill in $reasonable_timeframe, but that is
probably going to be case-by-case anyway)

> I propose that we adopt N=2. I think we should have stopped supporting
> RHEL8 this year (our yum repos won't be shipping PG19 builds for
> RHEL8). But I won't complain if consensus forms on N=3; I think it's
> just important that we arrive at some agreement on getting rid of RHEL
> 8.

It's too late to change anything for PG19, I think, so it kind of doesn't
matter today whether we set N to 2 or 3.  But I'd vote for N=3.  That
seems to match up better with LTS extended-support policies.

(I'm actually quite content with yum.pg.o cutting off support for
RHEL8 a year earlier than we stop supporting it at the source-code
level.  For one thing, we can pay attention to how much blowback
Devrim gets before we decide whether it's an okay source-code
change...)

			regards, tom lane

Re: PG20 Minimum Dependency Thread

Jacob Champion <jacob.champion@enterprisedb.com> — 2026-06-18T21:32:23Z

On Thu, Jun 18, 2026 at 2:06 PM Daniel Gustafsson <daniel@yesql.se> wrote:
> The entire OpenSSL 3.x line will be down to just 3.5 LTS by the time we ship
> v20.

Yeah. Though RH have been apparently shipping breaking updates to
OpenSSL in RHEL 9+, so the conversation may look completely different
when we get to those EOLs.

> One complicating factor when it comes to OpenSSL is that we need the 1.1.1 API
> support in order to keep LibreSSL supported.

True -- but I think that even if your split didn't land, surrounding
the necessary code with `#ifdef LIBRESSL_VERSION_NUMBER` would be a
big maintainability upgrade compared to "all code paths must support
both OpenSSL 1.1.1 _and_ LibreSSL which is
kind-of-not-really-the-same".

--Jacob

Re: PG20 Minimum Dependency Thread

Jacob Champion <jacob.champion@enterprisedb.com> — 2026-06-18T21:42:50Z

On Thu, Jun 18, 2026 at 2:22 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> FWIW, my impression of that thread was that we had agreed on pretty
> much everything except the value of N; if there was some later meeting
> that discussed it further, I wasn't there.

Cool.

> (hmm, I guess we didn't fill in $reasonable_timeframe, but that is
> probably going to be case-by-case anyway)

Sure. The first instance, if/when it happens, would probably be a trendsetter.

> It's too late to change anything for PG19, I think,

(right -- I didn't intend to propose a retroactive change, sorry for
any confusion)

> so it kind of doesn't
> matter today whether we set N to 2 or 3.

I think it still matters for impending decisions. For example, we're
about to engineer how to backport a sliding window of Python across
the sliding window of backbranch support. Shorter windows tie our
hands less.

But I agree that if that other thread is otherwise settled, we've
effectively declared that RHEL 9 is the minimum for PG20, and that
would make me very happy.

Thanks,
--Jacob

Re: PG20 Minimum Dependency Thread

Tom Lane <tgl@sss.pgh.pa.us> — 2026-06-18T22:26:06Z

Jacob Champion <jacob.champion@enterprisedb.com> writes:
> On Thu, Jun 18, 2026 at 2:22 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> so it kind of doesn't
>> matter today whether we set N to 2 or 3.

> I think it still matters for impending decisions. For example, we're
> about to engineer how to backport a sliding window of Python across
> the sliding window of backbranch support. Shorter windows tie our
> hands less.

I dunno.  One of the points of the allegedly-agreed-to policy
framework was

>>> 2) We don't remove support for OS versions in minor releases

A strict reading of that is that a released branch can't increase
its minimum required Python version.

Now maybe we can finesse that, like "you can build PL/Python and
associated contrib modules with Python >= X, but if you want to
run these optional tests, they require Python >= Y".  Not sure
how comfortable I am with that.  I definitely don't want to get
into a situation where we require buildfarm owners to have
Python >= Y installed, because then we will not have any testing
that proves we didn't break the other part.  (So we'd need a
runtime check to skip these tests on too-old Python.)

In any case, if we do make such a decision, most likely we'd
use the same value of Y for all the active back branches.
So I think the value of N in the support policy really
only matters for future version-cutoff decisions.

			regards, tom lane

Re: PG20 Minimum Dependency Thread

Tom Lane <tgl@sss.pgh.pa.us> — 2026-06-18T23:35:14Z

I wrote:
> Now maybe we can finesse that, like "you can build PL/Python and
> associated contrib modules with Python >= X, but if you want to
> run these optional tests, they require Python >= Y".  Not sure
> how comfortable I am with that.  I definitely don't want to get
> into a situation where we require buildfarm owners to have
> Python >= Y installed, because then we will not have any testing
> that proves we didn't break the other part.  (So we'd need a
> runtime check to skip these tests on too-old Python.)

Granting that our pytest framework should silently give up if
Python is too old, the decision of which minimum version to target
is really kind of independent of what PL/Python does.  It becomes
a tradeoff of ease of coding versus "how many platforms do you want
this test to be able to run on?".  I have no insight on what the
coding benefits are of different Python versions, but I do have
this freshly-scraped data about how many buildfarm members are
reporting which major Python version:

      3 3.5
     39 3.6
      5 3.7
      5 3.8
     39 3.9
      6 3.10
     21 3.11
     45 3.12
     48 3.13
     12 3.14
      2 3.15

Just eyeing that, it seems like 3.9 or 3.11 would be choices that
still allow most animals to run the tests.

			regards, tom lane

Re: PG20 Minimum Dependency Thread

Tristan Partin <tristan@partin.io> — 2026-06-19T04:49:18Z

On Thu Jun 18, 2026 at 6:35 PM CDT, Tom Lane wrote:
> I wrote:
>> Now maybe we can finesse that, like "you can build PL/Python and
>> associated contrib modules with Python >= X, but if you want to
>> run these optional tests, they require Python >= Y".  Not sure
>> how comfortable I am with that.  I definitely don't want to get
>> into a situation where we require buildfarm owners to have
>> Python >= Y installed, because then we will not have any testing
>> that proves we didn't break the other part.  (So we'd need a
>> runtime check to skip these tests on too-old Python.)
>
> Granting that our pytest framework should silently give up if
> Python is too old, the decision of which minimum version to target
> is really kind of independent of what PL/Python does.  It becomes
> a tradeoff of ease of coding versus "how many platforms do you want
> this test to be able to run on?".  I have no insight on what the
> coding benefits are of different Python versions, but I do have
> this freshly-scraped data about how many buildfarm members are
> reporting which major Python version:
>
>       3 3.5
>      39 3.6
>       5 3.7
>       5 3.8
>      39 3.9
>       6 3.10
>      21 3.11
>      45 3.12
>      48 3.13
>      12 3.14
>       2 3.15
>
> Just eyeing that, it seems like 3.9 or 3.11 would be choices that
> still allow most animals to run the tests.

The latest versions of pytest require Python >= 3.10. In theory, we
could pin to an older pytest version.

For what it's worth, the latest version of Meson supports Python >=
3.7. I wonder if we should tie our Meson and pytest versions together 
such that they support the same Python version.

-- 
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)

Re: PG20 Minimum Dependency Thread

Andrew Dunstan <andrew@dunslane.net> — 2026-06-19T13:39:20Z

On 2026-06-18 Th 6:26 PM, Tom Lane wrote:
> Jacob Champion <jacob.champion@enterprisedb.com> writes:
>> On Thu, Jun 18, 2026 at 2:22 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> so it kind of doesn't
>>> matter today whether we set N to 2 or 3.
>> I think it still matters for impending decisions. For example, we're
>> about to engineer how to backport a sliding window of Python across
>> the sliding window of backbranch support. Shorter windows tie our
>> hands less.
> I dunno.  One of the points of the allegedly-agreed-to policy
> framework was
>
>>>> 2) We don't remove support for OS versions in minor releases
> A strict reading of that is that a released branch can't increase
> its minimum required Python version.
>
> Now maybe we can finesse that, like "you can build PL/Python and
> associated contrib modules with Python >= X, but if you want to
> run these optional tests, they require Python >= Y".  Not sure
> how comfortable I am with that.  I definitely don't want to get
> into a situation where we require buildfarm owners to have
> Python >= Y installed, because then we will not have any testing
> that proves we didn't break the other part.  (So we'd need a
> runtime check to skip these tests on too-old Python.)
>
> In any case, if we do make such a decision, most likely we'd
> use the same value of Y for all the active back branches.
> So I think the value of N in the support policy really
> only matters for future version-cutoff decisions.
>
> 			


Buildfarm owners are going to have to opt in to pytest, in the same way 
that today they have to opt in to TAP tests, and in the same way there 
will be up front tests to check that what's installed meets the 
requirements. We could stick with X = 3.6 and make Y = 3.8.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Re: PG20 Minimum Dependency Thread

Jacob Champion <jacob.champion@enterprisedb.com> — 2026-06-19T18:18:51Z

On Thu, Jun 18, 2026 at 4:35 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Granting that our pytest framework should silently give up if
> Python is too old, the decision of which minimum version to target
> is really kind of independent of what PL/Python does.  It becomes
> a tradeoff of ease of coding versus "how many platforms do you want
> this test to be able to run on?".

Right.

> I have no insight on what the
> coding benefits are of different Python versions, but I do have
> this freshly-scraped data about how many buildfarm members are
> reporting which major Python version:

wrasse too (Python 3.4.3, Solaris 11.3), which tests PG14-16.

In fact I want to use wrasse as a case study here...

> >>> 2) We don't remove support for OS versions in minor releases
> A strict reading of that is that a released branch can't increase
> its minimum required Python version.

Solaris 11.3 was released in October 2015, with Python 2.6, 2.7, and
3.6. Standard support ended in 2021. So with your stricter reading of
the OS support policy, and N=3, it's lucky that we happened to drop
Python 2 support already. Otherwise, Solaris 11.3 would pin Python 2.6
support until PG17 drops off the matrix in 2028, fifteen years after
end of life.

I think that's patently unreasonable. We should either not adopt that
stricter reading, or else be a lot more proactive in pushing our
minimum dependency list forwards for every release, which is going to
feel punitive.

(Oracle themselves removed Python 2.6 support in the middle of their
11.3 support cycle. The Solaris 11.4 standard support window is now
ten years (2021-2031), and the versions of Python they support today
do not overlap at all with the Python versions they supported at 11.4
GA.)

--Jacob

Re: PG20 Minimum Dependency Thread

Peter Eisentraut <peter@eisentraut.org> — 2026-06-20T13:16:04Z

On 18.06.26 22:01, Jacob Champion wrote:
> ...because I don't see one yet, and upcoming things like the Python
> test port are going to need clarity in advance, and I wanna stir up
> trouble right before I go eat lunch.
> 
> = Background =
> 
> The most recent (mailing list) discussions I am aware of are at
> 
> [1] https://postgr.es/m/16098.1745079444%40sss.pgh.pa.us (Python)
> [2] https://postgr.es/m/42e13eb0-862a-441e-8d84-4f0fd5f6def0%40eisentraut.org
> (Meson)

Here is another relevant thread:

https://www.postgresql.org/message-id/flat/CA+hUKGL7trhWiJ4qxpksBztMMTWDyPnP1QN+Lq341V7QL775DA@mail.gmail.com

This is now "ready for committer" for PG20 and would de-support RHEL 7.

Another unrelated data point is that making PL/Python thread-safe (at 
least in the way I have worked out) would require Python 3.10.

(But RHEL provides a supported way to install newer Python versions, so 
this doesn't necessarily have to mean de-supporting a given RHEL version 
altogether.  I don't have an opinion on that at this time.)

Re: PG20 Minimum Dependency Thread

Zsolt Parragi <zsolt.parragi@percona.com> — 2026-06-21T07:57:45Z

> But RHEL provides a supported way to install newer Python versions, so
> this doesn't necessarily have to mean de-supporting a given RHEL version
> altogether. I don't have an opinion on that at this time

That's possible on most (all?) platforms (pyenv/asdf/uv/mise/...). All
with a question mark because I have no idea which of these would work
on solaris, but some of them are pure bash scripts so those should
work. (and that ignores windows, but that also shouldn't be an issue
generally). These would be per user custom built pythons, so they
would only work with the different plpython/pytest python approach,
but would allow using the latest python for the test suite on all
platforms.

Re: PG20 Minimum Dependency Thread

Andrew Dunstan <andrew@dunslane.net> — 2026-06-21T13:23:38Z

On 2026-06-21 Su 3:57 AM, Zsolt Parragi wrote:
>> But RHEL provides a supported way to install newer Python versions, so
>> this doesn't necessarily have to mean de-supporting a given RHEL version
>> altogether. I don't have an opinion on that at this time
> That's possible on most (all?) platforms (pyenv/asdf/uv/mise/...). All
> with a question mark because I have no idea which of these would work
> on solaris, but some of them are pure bash scripts so those should
> work. (and that ignores windows, but that also shouldn't be an issue
> generally). These would be per user custom built pythons, so they
> would only work with the different plpython/pytest python approach,
> but would allow using the latest python for the test suite on all
> platforms.
>
>

I think the idea is that we should be able to build with what the distro 
itself supports.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Re: PG20 Minimum Dependency Thread

Tom Lane <tgl@sss.pgh.pa.us> — 2026-06-21T14:02:49Z

Andrew Dunstan <andrew@dunslane.net> writes:
> On 2026-06-21 Su 3:57 AM, Zsolt Parragi wrote:
>> That's possible on most (all?) platforms (pyenv/asdf/uv/mise/...). All
>> with a question mark because I have no idea which of these would work
>> on solaris, but some of them are pure bash scripts so those should
>> work. (and that ignores windows, but that also shouldn't be an issue
>> generally). These would be per user custom built pythons, so they
>> would only work with the different plpython/pytest python approach,
>> but would allow using the latest python for the test suite on all
>> platforms.

> I think the idea is that we should be able to build with what the distro 
> itself supports.

Quite honestly, if we demand that buildfarm owners install some
version of python that their platform doesn't package, they will
simply not enable pytest testing.  Care and feeding of a BF
animal is already a nontrivial investment of effort.  I'm especially
not believing that people will install two different python versions
in support of this.

			regards, tom lane

Re: PG20 Minimum Dependency Thread

Jacob Champion <jacob.champion@enterprisedb.com> — 2026-06-22T20:50:37Z

On Sun, Jun 21, 2026 at 7:03 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > I think the idea is that we should be able to build with what the distro
> > itself supports.
>
> Quite honestly, if we demand that buildfarm owners install some
> version of python that their platform doesn't package

I know you're responding to a bunch of people arguing different
things, but you and I are in agreement that when it comes to the
*core* testing framework, an out-of-distro Python installation
requirement is not what we should be targeting for "supported
platforms". And I don't think we're going to need that.

> I'm especially
> not believing that people will install two different python versions
> in support of this.

I have a much harder time agreeing with this. The end user experience
we're going for is

    $ sudo dnf install python3.12-pytest
    $ meson configure -DPYTEST=pytest-3.12
    $ ninja reconfigure
    ...
    pytest                   : /usr/bin/pytest-3.12 7.4.2
    ...
    plpython                 : YES 3.9

That's not a burden. I doubt we'd be able to achieve that right away
with all of the PG15 supported platforms, but it's hard to believe we
couldn't get there eventually. (The above is from Rocky 9.)

--Jacob

Re: PG20 Minimum Dependency Thread

Jacob Champion <jacob.champion@enterprisedb.com> — 2026-07-08T17:29:45Z

On Fri, Jun 19, 2026 at 11:18 AM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> Solaris 11.3 was released in October 2015, with Python 2.6, 2.7, and
> 3.6. Standard support ended in 2021. So with your stricter reading of
> the OS support policy, and N=3, it's lucky that we happened to drop
> Python 2 support already. Otherwise, Solaris 11.3 would pin Python 2.6
> support until PG17 drops off the matrix in 2028, fifteen years after
> end of life.

I pulled some data from the endoflife.date project [1] (which I
haven't completely verified yet, but seems to be at least somewhat
accurate). For a presumed PG20 release on 2027-09-23, our trailing
edge of distro support might look something like below. Conclusions up
front:

OpenSSL 1.1.1 is a problem. With N=2, we'd drop SLES 12.5, which
appears to be the final non-Oracle barrier to exit. (And I think we
should just declare 1.1.1 unsupported for PG20, regardless of N, but
in any case this gives weight to my preference of N=2.)

I additionally think we should take Solaris and Oracle Linux out of
the standard classification of "LTS". People who want to pay Oracle
for extended support of out-of-date Postgres versions are free to do
so without tying our development to RHEL8-vintage (or older)
dependencies for the next seven(!) years, or forcing us to lock into
an arbitrary snapshot of the Solaris rolling releases. We already
don't support OL7 because of OpenSSL 1.0.2.

If we did that, Python 3.9 looks within reach for PG20, which seems
reasonable considering it'll already have been dead for two years. (It
looks like LTS support for a spectrum of Pythons is now the norm
rather than the exception, and we should start making decisions
accordingly.) That'd only be a roadbump for our SUSE buildfarm owners,
who'd need to install an additional package beside the base Python 3.6
in order to run Python scripts.

= LTS Distros (N=3) =

Amazon Linux 2023 (End of Service 2027, End of Life 2029)
- Python 3.9 to 3.14+
- OpenSSL 3.0
Debian 12 Bookworm (EoS 2026, EoL 2028)
- Python 3.11
- OpenSSL 3.0
Oracle Linux 7 (EoS 2024-12, EoL 2028)
- Python 3.6 to 3.8
- OpenSSL 1.0.2 (!!)
RHEL/Rocky/Alma/CentOS Stream 9 (EoS 2027, EoL 2032/2035)
- Python 3.9 to 3.12+
- OpenSSL 3.0 (3.2? 3.5?)
SLES 12.5 (EoS 2024-10, EoL 2027)
- Python 3.4 to 3.6
- OpenSSL 1.1.1 (!)
Solaris 11.4 (EoS 2031, EoL 2037)
- Python 3.9 to 3.11 (rolling?)
- OpenSSL 3.0 (3.5 planned?)
Ubuntu 22.04 Jammy (EoS 2024-09, EoL 2027/2032)
- Python 3.10 to 3.11
- OpenSSL 3.0
Windows 11 24H2 Enterprise (EoS 2027, EoL 2029/2034)
Windows Server 2022 (EoS 2026, EoL 2031)

= LTS Distros (N=2) =

Only a few change:

Oracle Linux 8 (EoS 2029, EoL 2032)
- Python 3.8 to 3.12+
- OpenSSL 1.1.1 (!)
SLES 15.6 (EoS 2025-12, EoL 2028)
- Python 3.6 to 3.12+
- OpenSSL 3.1
Ubuntu 24.04 Noble (EoS 2029, EoL 2036)
- Python 3.12
- OpenSSL 3.0

= Non-LTS Distros (N=0?) =

I don't think this was explicitly discussed, but hopefully no one
feels the need to guarantee support for non-LTS distributions that go
EoL before we even release. (I.e. N is effectively zero for those
distros.) But buildfarm operators still need some baseline, and here's
what I think they could be for PG20:

AIX 7.2 TL5 (EoL TBD?)
- Python 3.10+ (?)
- OpenSSL 3.0
Alpine 3.23 (EoL 2027-11)
- Python 3.12
- OpenSSL 3.5
Fedora 45 (EoL 2027-11)
- probably Python 3.15
- probably OpenSSL 4.0
FreeBSD 14.x (EoL 2028)
- Python 3.11+
- OpenSSL 3.0
macOS 15 (Sequoia) (EoL 2027-09)
NetBSD 10.x (EoL TBD)
- Python 3.11 to 3.14
- OpenSSL 3.0
OpenBSD 8.0 (EoL TBD)
- Python 3.11 to 3.14
- LibreSSL 4.4
OpenIndiana Hipster 2027.x (EoL TBD)
- probably Python 3.14+
- probably OpenSSL 4.0
OpenSUSE Leap 16.0 (EoL 2027-10)
- Python 3.13
- OpenSSL 3.5

Thanks,
--Jacob

[1] https://github.com/endoflife-date/endoflife.date