From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Lakhin <exclusion@gmail.com>
cc: pgsql-hackers <pgsql-hackers@postgresql.org>,
        Andres Freund <andres@anarazel.de>
Subject: Re: plpython tests fail against python 3.14 under Valgrind
In-reply-to: <f071e691-5930-4738-9dbd-43ed2da367fe@gmail.com>
References: <f071e691-5930-4738-9dbd-43ed2da367fe@gmail.com>
Comments: In-reply-to Alexander Lakhin <exclusion@gmail.com>
	message dated "Tue, 28 Jul 2026 08:00:01 +0300"
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <2322484.1786409724.0@sss.pgh.pa.us>
Date: Mon, 10 Aug 2026 20:56:22 -0400
Message-ID: <2322557.1786409782@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2322557.1786409782%40sss.pgh.pa.us>
Precedence: bulk

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <2322484.1786409724.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable

Alexander Lakhin <exclusion@gmail.com> writes:
> As buildfarm animal skink shows, upgrade to Python 3.14 breaks plpython
> tests under Valgrind [1]:
>  =C2=A061/400 plpython - postgresql:plpython/regress ERROR=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 49.88s=C2=A0=C2=A0=
 exit status 1

Yeah, I can reproduce this here, using Fedora 43 (with
python3-3.14.6-1.fc43.x86_64 and valgrind-3.27.1-1.fc43.x86_64).
As you say, it doesn't reproduce on master; I didn't take the trouble
to bisect.

> It's also not reproduced on master, probably just because of a bit lesse=
r
> stack usage. I've bisected the anomaly and found what makes master pass
> the tests: aeb07c55f.

Actually, I think it's the other way around: master uses more stack.
In v19, tzload() does this:

	union local_storage *lsp =3D malloc(sizeof *lsp);
	...
	free(lsp);

while in master it does this:

	union local_storage *lsp;
	union local_storage ls;

	lsp =3D &ls;

That's a sizeable amount of stack getting chewed:

(gdb) p sizeof(union local_storage)
$1 =3D 72240

However, we surely don't invoke tzload() while running any Python
code.  What I think must be happening is that at postmaster start,
or possibly backend start, we invoke tzload() while setting the
timezone GUC, and this causes a bunch of stack pages to get allocated,
more than we have in the v19 code path.  Somehow, python and valgrind
interact badly when there's not much pre-existing stack allocation.
It's pretty unclear which one is to blame, but it seems like it can't
be our fault.  (Although ... surely the standard python executable
invokes libpython with little pre-existing stack?  If that doesn't
trigger this problem, what are we doing differently?)

Anyway, I've confirmed that the attached patch makes the problem
go away here.  Unless somebody wants to expend brain cells on
running the underlying issue to ground, I think we should just
apply this to the back branches and be happy.  A variant plan
could be to do it like this #ifdef USE_VALGRIND and otherwise
keep the old code, but that seems unduly paranoid to me.

			regards, tom lane


------- =_aaaaaaaaaa0
Content-Type: text/x-diff; name="tzload-stack-hack-for-python.patch";
	charset="us-ascii"
Content-ID: <2322484.1786409724.2@sss.pgh.pa.us>
Content-Description: tzload-stack-hack-for-python.patch
Content-Transfer-Encoding: quoted-printable

diff --git a/src/timezone/localtime.c b/src/timezone/localtime.c
index fb04b4cf6bf..1a8088b520c 100644
--- a/src/timezone/localtime.c
+++ b/src/timezone/localtime.c
@@ -588,17 +588,10 @@ tzloadbody(char const *name, char *canonname, struct=
 state *sp, bool doextend,
 int
 tzload(char const *name, char *canonname, struct state *sp, bool doextend=
)
 {
-	union local_storage *lsp =3D malloc(sizeof *lsp);
+	union local_storage ls;
+	union local_storage *lsp =3D &ls;
 =

-	if (!lsp)
-		return errno;
-	else
-	{
-		int			err =3D tzloadbody(name, canonname, sp, doextend, lsp);
-
-		free(lsp);
-		return err;
-	}
+	return tzloadbody(name, canonname, sp, doextend, lsp);
 }
 =

 static bool

------- =_aaaaaaaaaa0--