Re: plpython tests fail against python 3.14 under Valgrind

Alexander Lakhin <exclusion(at)gmail(dot)com> writes:
> As buildfarm animal skink shows, upgrade to Python 3.14 breaks plpython
> tests under Valgrind [1]:
>  61/400 plpython - postgresql:plpython/regress ERROR             49.88s   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 lesser
> 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 = malloc(sizeof *lsp);
...
free(lsp);

while in master it does this:

union local_storage *lsp;
union local_storage ls;

lsp = &ls;

That's a sizeable amount of stack getting chewed:

(gdb) p sizeof(union local_storage)
$1 = 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