Обсуждение: Re: Use Python "Limited API" in PL/Python

On 02.12.24 09:51, Peter Eisentraut wrote:
> This patch changes PL/Python to use the Python "limited API". This API 
> has stronger ABI stability guarantees.[0] This means, you can build PL/ 
> Python against any Python 3.x version and use any other Python 3.x 
> version at run time.
> 
> This is especially useful for binary packages where the operating system 
> does not come with a fixed suitable version of Python. For example, 
> Postgres.app (for macOS) would prefer to link against the Python version 
> supplied by python.org (Python.app). But that has a 3.x version that 
> changes over time. So instead they bundle a Python version inside 
> Postgres.app. The Windows installer used to also bundle Python but as of 
> PG17 you have to get it yourself, but you have to get a very specific 
> version [1], which is unsatisfactory. This patch fixes that: You can use 
> any Python version independent of what PL/Python was built against. 
> (There is a mechanism to say "at least 3.N", but for this patch, we 
> don't need that, we can stick with the current minimum of 3.2.)
> 
> (I have only tested the macOS side of this, not the Windows side. In 
> fact, the patch currently doesn't build on Windows on CI. I haven't 
> figured out why.)

A bit more exploration of that Windows build failure:

This patch changes it so that, on Windows, plpython is linked against a 
library called "python3.lib" instead of previously "python311.lib" or 
similar.  The build failure is [0]

     LINK : fatal error LNK1104: cannot open file 'python3.lib'

[0]: https://cirrus-ci.com/task/5738515637469184

which suggests that the file isn't there.  But we have tested this 
internally and the build succeeded locally.  I also don't see anything 
in the Python installer code or documentation that suggests that there 
is an option not to install that file or something like that.  It should 
be installed right next to the python3XX.lib file.

How could one debug this?  Is there a way to log into the CI image or 
get a directory dump or something like that?

On 15.01.25 23:20, Peter Eisentraut wrote:
> On 15.01.25 12:28, Jakob Egger wrote:
>> On 14.01.2025, at 16:51, Jakob Egger <jakob@eggerapps.at> wrote:
>>> I've tried to create a patch with this change. I'm attaching it to 
>>> this message so that cfbot picks it up. (I was unable to reproduce 
>>> the issue locally)
>>
>> Apologies, please disregard my last patch. It does not work.
>>
>> It looks like meson just can't build libraries that link with Python 
>> that use the limited API.
>>
>> My understanding of Meson is limited, so I am unsure how to best work 
>> around this limitation.
>>
>> I've spent two days trying to figure it out; I'm at the end of my wits.
> 
> Thanks for checking.  I've also been poking at this, without success.
> 
> What we could do is just not activate the limited API on Windows 
> (actually MSVC, since it works on MinGW).  If someone later finds a way 
> to make it work on Windows/MSVC, then it's easy to change.
> 
> So here is an updated patch set with that change.  It should pass cfbot 
> like this.

Update for the hackers list: This patch set was briefly committed but 
had to be reverted because it crashed on some older Python versions; see 
[0].

I have locally reproduced the problem with Python 3.6 and 3.7; Python 
3.8 is ok.  This matches the results from the buildfarm.

I have poked at this a bit more but haven't gotten a good idea where or 
how to fix it so far.  Help welcome.


[0]: 
https://www.postgresql.org/message-id/flat/E1tnJNu-000CZW-0X%40gemulon.postgresql.org

On 03.03.25 11:17, Peter Eisentraut wrote:
> Update for the hackers list: This patch set was briefly committed but 
> had to be reverted because it crashed on some older Python versions; see 
> [0].
> 
> I have locally reproduced the problem with Python 3.6 and 3.7; Python 
> 3.8 is ok.  This matches the results from the buildfarm.
> 
> I have poked at this a bit more but haven't gotten a good idea where or 
> how to fix it so far.  Help welcome.

I have figured this out.  There was a Python API change/bugfix between 
3.7 and 3.8 that directly affects this patch.  The relevant commit is 
<https://github.com/python/cpython/commit/364f0b0f19c>.  I have applied 
the workarounds described there to my patch set, and now it works for 
3.6 and 3.7 as well.

On 05.03.25 17:40, Peter Eisentraut wrote:
> On 03.03.25 11:17, Peter Eisentraut wrote:
>> Update for the hackers list: This patch set was briefly committed but 
>> had to be reverted because it crashed on some older Python versions; 
>> see [0].
>>
>> I have locally reproduced the problem with Python 3.6 and 3.7; Python 
>> 3.8 is ok.  This matches the results from the buildfarm.
>>
>> I have poked at this a bit more but haven't gotten a good idea where 
>> or how to fix it so far.  Help welcome.
> 
> I have figured this out.  There was a Python API change/bugfix between 
> 3.7 and 3.8 that directly affects this patch.  The relevant commit is 
> <https://github.com/python/cpython/commit/364f0b0f19c>.  I have applied 
> the workarounds described there to my patch set, and now it works for 
> 3.6 and 3.7 as well.

This has all been committed now.

On Fri, 14 Mar 2025 at 14:11, Peter Eisentraut <peter@eisentraut.org> wrote:
>
> On 05.03.25 17:40, Peter Eisentraut wrote:
> > On 03.03.25 11:17, Peter Eisentraut wrote:
> >> Update for the hackers list: This patch set was briefly committed but
> >> had to be reverted because it crashed on some older Python versions;
> >> see [0].
> >>
> >> I have locally reproduced the problem with Python 3.6 and 3.7; Python
> >> 3.8 is ok.  This matches the results from the buildfarm.
> >>
> >> I have poked at this a bit more but haven't gotten a good idea where
> >> or how to fix it so far.  Help welcome.
> >
> > I have figured this out.  There was a Python API change/bugfix between
> > 3.7 and 3.8 that directly affects this patch.  The relevant commit is
> > <https://github.com/python/cpython/commit/364f0b0f19c>.  I have applied
> > the workarounds described there to my patch set, and now it works for
> > 3.6 and 3.7 as well.
>
> This has all been committed now.

I felt we can mark this commitfest entry at [1] to commited now.
[1] - https://commitfest.postgresql.org/patch/5416/

Regards,
Vignesh

On 1/15/2025 5:28 AM, Jakob Egger wrote:
> On 14.01.2025, at 16:51, Jakob Egger <jakob@eggerapps.at> wrote:
>> I've tried to create a patch with this change. I'm attaching it to this message so that cfbot picks it up. (I was
unableto reproduce the issue locally)
 
> 
> Apologies, please disregard my last patch. It does not work.
> 
> It looks like meson just can't build libraries that link with Python that use the limited API.
> 
> My understanding of Meson is limited, so I am unsure how to best work around this limitation.
> 
> I've spent two days trying to figure it out; I'm at the end of my wits.
> 
> Best regards,
> Jakob
Hi Jakob and Peter,

I've been working on enabling the Python Limited API on MSVC, which was
disabled in the recent commit due to build failures.

The issue is that Meson doesn't automatically link against python3.lib
when using the Limited API. Meson's Python dependency always returns the
version-specific library (python3XX.lib) regardless of whether
limited api is defined. This appears to be a known Meson limitation:
https://github.com/mesonbuild/meson/issues/13824

Initially, I thought that maybe the library wasn't being installed, but
that is not the case and the patch to our CI Windows MSVC image is not
needed.

I have a patch that works around this by manually constructing the
Python dependency on MSVC to use python3.lib instead of python3XX.lib,
using cc.find_library('python3') and building the dependency with the
appropriate include directory.  It passes CI when I push.  I'll see what
cfbot thinks.

Still testing, but wanted to share progress and get feedback on the
approach.

-- 
Bryan Green
EDB: https://www.enterprisedb.com

On 1/2/2026 11:40 AM, Bryan Green wrote:
> On 1/15/2025 5:28 AM, Jakob Egger wrote:
>> On 14.01.2025, at 16:51, Jakob Egger <jakob@eggerapps.at> wrote:
>>> I've tried to create a patch with this change. I'm attaching it to this message so that cfbot picks it up. (I was
unableto reproduce the issue locally)
 
>>
>> Apologies, please disregard my last patch. It does not work.
>>
>> It looks like meson just can't build libraries that link with Python that use the limited API.
>>
>> My understanding of Meson is limited, so I am unsure how to best work around this limitation.
>>
>> I've spent two days trying to figure it out; I'm at the end of my wits.
>>
>> Best regards,
>> Jakob
> Hi Jakob and Peter,
> 
> I've been working on enabling the Python Limited API on MSVC, which was
> disabled in the recent commit due to build failures.
> 
> The issue is that Meson doesn't automatically link against python3.lib
> when using the Limited API. Meson's Python dependency always returns the
> version-specific library (python3XX.lib) regardless of whether
> limited api is defined. This appears to be a known Meson limitation:
> https://github.com/mesonbuild/meson/issues/13824
> 
> Initially, I thought that maybe the library wasn't being installed, but
> that is not the case and the patch to our CI Windows MSVC image is not
> needed.
> 
> I have a patch that works around this by manually constructing the
> Python dependency on MSVC to use python3.lib instead of python3XX.lib,
> using cc.find_library('python3') and building the dependency with the
> appropriate include directory.  It passes CI when I push.  I'll see what
> cfbot thinks.
> 
> Still testing, but wanted to share progress and get feedback on the
> approach.
> 

cfbot seems to be happy:
https://cirrus-ci.com/github/postgresql-cfbot/postgresql/cf%2F6369
-- 
Bryan Green
EDB: https://www.enterprisedb.com

On 02.01.26 18:40, Bryan Green wrote:
> I have a patch that works around this by manually constructing the
> Python dependency on MSVC to use python3.lib instead of python3XX.lib,
> using cc.find_library('python3') and building the dependency with the
> appropriate include directory.  It passes CI when I push.  I'll see what
> cfbot thinks.
> 
> Still testing, but wanted to share progress and get feedback on the
> approach.

This approach seems fine to me.  I suppose one question would be whether 
it would be worth using that same approach on all platforms rather than 
just on windows/msvc.  That way we only have one code path to maintain. 
But I'm not sure how easy that would be to achieve.

On 02.01.26 19:12, Bryan Green wrote:
>> I have a patch that works around this by manually constructing the
>> Python dependency on MSVC to use python3.lib instead of python3XX.lib,
>> using cc.find_library('python3') and building the dependency with the
>> appropriate include directory.  It passes CI when I push.  I'll see what
>> cfbot thinks.
>>
>> Still testing, but wanted to share progress and get feedback on the
>> approach.
>>
> 
> cfbot seems to be happy:
> https://cirrus-ci.com/github/postgresql-cfbot/postgresql/cf%2F6369

Another thing you could test is whether this actually makes the ABI 
stable.  So for example build PL/Python against Python 3.13 and then 
install Python 3.14 (and uninstall 3.13 just to be sure) and then start 
a server and run some PL/Python stuff.