Re: [PATCH] pl: fix can not build free-thread for plpython extension like 3.14t

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 洪伊 <zouzou0208(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] pl: fix can not build free-thread for plpython extension like 3.14t
Date: 2026-01-16 16:14:54
Message-ID: e662be88-5415-4dc6-b0d7-5cdcaf1d01cb@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. ;-)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Borodin 2026-01-16 16:17:21 Re: Compression of bigger WAL records
Previous Message Matheus Alcantara 2026-01-16 16:07:25 Re: support ALTER COLUMN SET EXPRESSION over virtual generated column with check constraint