PG20 Minimum Dependency Thread

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

Jacob Champion <jacob.champion@enterprisedb.com> writes:

The most recent (mailing list) discussions I am aware of are at
[1] /messages/by-id/16098.1745079444@sss.pgh.pa.us (Python)
[2] /messages/by-id/42e13eb0-862a-441e-8d84-4f0fd5f6def0@eisentraut.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

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

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

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

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

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)