From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: What's our minimum supported Python version? |
Date: | 2025-04-24 08:53:48 |
Message-ID: | 5391e576-d44c-4d02-80ea-a50b8047ce75@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 22.04.25 18:04, Tom Lane wrote:
> Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> writes:
>> As for picking a version... 3.6 will have been EOL for almost three
>> years by the time 18 releases. It seems like we would drop it happily,
>> were it not for RHEL8.
>
> Agreed, but RHEL8 is out there and I don't think we can just drop
> support for it. I'm also not excited by the idea that an incidental
> test script gets to dictate what the cutoff is.
>
> I do think we should stop claiming that Python 3.2 will work.
> (Maybe it does, but we don't know that.) I see that the configure
> script only checks for Python >= 3, and it doesn't look like the
> meson scripts check explicitly at all, although there's a comment
> saying that our meson version cutoff is intended to allow working
> with Python 3.5.
>
> Maybe it's sufficient to make a documentation change here, and
> say we support Python >= 3.5? I'd be okay with saying 3.6.8
> too, on the grounds that if anything older fails to work we'd
> almost certainly just say "too bad". But RHEL8 is widespread
> enough that I think we need to keep making the effort for 3.6.8.
There are a lot of different things that are meant by Python support
nowadays.
It used to be the case that the minimum Python version was (1) the
oldest version that was required to get plpython to compile, and (2) the
range of versions for which we would maintain "expected" files for the
plpython tests (see history of src/pl/plpython/expected/README).
#2 isn't really a problem anymore, it seems. It used to require yearly
attention, but not anymore. (Maybe Python itself has gotten more
stable, or we have changed our tests to be less sensitive to this,
probably a combination of both.)
#1 is also less of a hot-spot, as indicated that we still claim to
support back to Python 3.2. Also, starting in PG18, we are using the
Python "Limited API", so this is being enforced on the Python side.
That means, in principle, if plpython compiles successfully right now on
Python 3.13, then it should also compile successfully on Python 3.2.
But now the new meanings are also, (3) what version of Python is
required by the oldest supported Meson version, and (4) what version of
Python can be assumed by various build and test scripts. There is
actually (4a) scripts that are only run from a meson build, which should
surely align with #3, and (4b) scripts that are also run by a make
build, which is what oauth_server.py is, for which we can pick anything.
The answer to #3 is currently Python 3.5 (see top of top-level
meson.build).
And then there is meaning (5) what version has anyone actually tested.
Note that #2, #3, and #4 are build-time and #1 also has a run-time
component. It would be plausible to say that you need a certain newer
Python to build, but plpython can still run on older versions. If we
were to make any changes, we need to make sure that the documentation is
precise about this and matches the code (see #define Py_LIMITED_API).
The cut-off in practice for these things is usually RHEL. PG18
currently still supports RHEL 7, which appears to come with Python 3.6.
Seeing that the small problem with the test script was easily fixed, I
think we should stick with that for now. There might be value in
dropping support for RHEL 7 sometime, but that should be done across the
board (meson version, openssl version, perl version, etc.), and requires
some buildfarm changes, so I wouldn't do this right now.
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2025-04-24 09:09:24 | Re: long-standing data loss bug in initial sync of logical replication |
Previous Message | Frédéric Yhuel | 2025-04-24 08:46:39 | Re: [BUG] temporary file usage report with extended protocol and unnamed portals |