[PATCH] pl: fix can not build free-thread for plpython extension like 3.14t
Hi dear hackers:
This patch fix can not build plpython for free-thread python like
python3.14t
which 3.14t is maintain in cpython team
it needs to open the py_limited_api for free-thread build
Thanks
Hong Yi
Attachments:
v1-0001-Fix-PL-Python-build-with-Python-3.13-3.14-free-th.patchapplication/octet-stream; name=v1-0001-Fix-PL-Python-build-with-Python-3.13-3.14-free-th.patchDownload
From 6e5eb1331559452e23ce5b381b9c3cab011c8cb4 Mon Sep 17 00:00:00 2001
From: yihong0618 <zouzou0208@gmail.com>
Date: Thu, 15 Jan 2026 14:40:33 +0800
Subject: [PATCH v1] Fix PL/Python build with Python 3.13/3.14 free-threaded
builds
The free-threaded build requires extension artifacts built specifically
for the t-suffixed ABI (e.g. python3.13t). It also does not support the
Limited C API / stable ABI, so py_limited_api must be disabled when
Py_GIL_DISABLED is set. See CPython docs "Building Extensions for the
Free-Threaded Build".
Signed-off-by: yihong0618 <zouzou0208@gmail.com>
---
src/pl/plpython/plpython.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/pl/plpython/plpython.h b/src/pl/plpython/plpython.h
index d0745bb68af..16b8c905dfb 100644
--- a/src/pl/plpython/plpython.h
+++ b/src/pl/plpython/plpython.h
@@ -27,10 +27,14 @@
* Enable Python Limited API
*
* XXX currently not enabled on MSVC because of build failures
+ * XXX currently not enabled for python free-thread build
*/
#if !defined(_MSC_VER)
+#include <pyconfig.h>
+#if !defined(Py_GIL_DISABLED)
#define Py_LIMITED_API 0x03020000
#endif
+#endif
/*
* Pull in Python headers via a wrapper header, to control the scope of
--
2.49.0
=?UTF-8?B?5rSq5LyK?= <zouzou0208@gmail.com> writes:
This patch fix can not build plpython for free-thread python like
python3.14t
We've gone to fairly considerable trouble to switch to using Python's
limited API, for reasons described here:
/messages/by-id/ee410de1-1e0b-4770-b125-eeefd4726a24@eisentraut.org
I don't see why we should abandon that for the convenience of
somebody's evidently-nonstandard Python build.
The proposed patch also breaks the header isolation that
the separate plpython_system.h header is meant to maintain.
Arguably we should have #define'd Py_LIMITED_API inside
plpython_system.h, not where it is. But I don't feel a need
to mess with that without a far better argument for why
we should change this at all.
regards, tom lane
Hi
I understand the reason for using Py_LIMITED_API, and python 3.14t is a
standard build from cpython team.
link:
https://docs.python.org/3/whatsnew/3.14.html#whatsnew314-free-threaded-now-supported
It seems the only way to build plpython for free-thread python is to use
Py_LIMITED_API, otherwise it fails to build.
Thanks
Hong Yi
On Fri, Jan 16, 2026 at 12:01 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Show quoted text
=?UTF-8?B?5rSq5LyK?= <zouzou0208@gmail.com> writes:
This patch fix can not build plpython for free-thread python like
python3.14tWe've gone to fairly considerable trouble to switch to using Python's
limited API, for reasons described here:/messages/by-id/ee410de1-1e0b-4770-b125-eeefd4726a24@eisentraut.org
I don't see why we should abandon that for the convenience of
somebody's evidently-nonstandard Python build.The proposed patch also breaks the header isolation that
the separate plpython_system.h header is meant to maintain.
Arguably we should have #define'd Py_LIMITED_API inside
plpython_system.h, not where it is. But I don't feel a need
to mess with that without a far better argument for why
we should change this at all.regards, tom lane
=?UTF-8?B?5rSq5LyK?= <zouzou0208@gmail.com> writes:
I understand the reason for using Py_LIMITED_API, and python 3.14t is a
standard build from cpython team.
AIUI, the "limited API" was devised by the Python community as an
API/ABI subset that they are prepared to guarantee holds stable
for every Python 3.x release, full stop. I think you're going
to have a hard time convincing us that there is anything standard
about a Python variant that can't handle client code built against
that API.
regards, tom lane
Got your point and make sense thank you very much.
Tom Lane <tgl@sss.pgh.pa.us>于2026年1月16日 周五12:43写道：
Show quoted text
=?UTF-8?B?5rSq5LyK?= <zouzou0208@gmail.com> writes:
I understand the reason for using Py_LIMITED_API, and python 3.14t is a
standard build from cpython team.AIUI, the "limited API" was devised by the Python community as an
API/ABI subset that they are prepared to guarantee holds stable
for every Python 3.x release, full stop. I think you're going
to have a hard time convincing us that there is anything standard
about a Python variant that can't handle client code built against
that API.regards, tom lane
I tried to investigate this by installing python314-freethreading from
MacPorts on a handy Mac machine. I got this note during install:
python314-freethreading has the following notes:
Python with free threading has a different ABI and is thus
incompatible with extension modules built for the standard ABI.
and then this while trying to build PG:
/opt/local/Library/Frameworks/Python.framework/Versions/3.14t/include/python3.14t/Python.h:52:4: error: "The limited API is not currently supported in the free-threaded build"
So you're right that it's broken. But I can only read this in one
of two ways:
1. The free-threaded build is not actually meant to be production
ready at this point,
or
2. The limited API's promise of API/ABI stability is a lie.
I prefer explanation #1. But I do not think people using Postgres
are particularly interested in development branches of Python, and if
they are, they can surely adjust the Postgres source for themselves.
It would not serve our own project's goals to ship Postgres builds
that are incompatible with the standard limited API.
regards, tom lane
On 16.01.26 06:24, Tom Lane wrote:
So you're right that it's broken. But I can only read this in one
of two ways:1. The free-threaded build is not actually meant to be production
ready at this point,
or
2. The limited API's promise of API/ABI stability is a lie.I prefer explanation #1. But I do not think people using Postgres
are particularly interested in development branches of Python, and if
they are, they can surely adjust the Postgres source for themselves.
It would not serve our own project's goals to ship Postgres builds
that are incompatible with the standard limited API.
I don't think there is an expectation that there will be ABI
compatibility between free-threaded and normal builds; that's why they
put the "t" in the version number to call that out. So I don't think
there is a contradiction here. If you're on a normal build, you can opt
into the ABI stability offer (or not), if you're on a free-threaded
build, you don't have that option (yet).
So the proposed patch seems valid, maybe up to some header include
reshuffling.
But what's not clear to me is whether the PL/Python C code is ready to
be run under a free-threaded interpreter. I didn't see any way for an
extension to be opt into being run under this model, so I guess they
expect that most code will be fine by now. (I suppose you can opt out
by testing Py_GIL_DISABLED.) If PL/Python were a trusted PL, I would
definitely be very concerned; now I'm only somewhat concerned. ;-)