Re: Re-add recently-removed tests for ltree and intarray
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-05-15T02:09:29Z
Lists: pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes: > Some of you may have noticed that some regression tests have been > removed due to some noise in the buildfarm, as of commit 906ea101d0d5. > We did not have time to do something for this release, unfortunately. > It is possible to reproduce the incompatibility by setting > max_stack_depth to a low value, where the first new query of ltree and > intarray would fail, when written in their original shape. Just to add a little more color to this --- what we discovered after there was time for some investigation was that: (a) the stack-overflow failure occurred in the findoprnd() function of intarray/_int_bool.c or ltree/ltxtquery_io.c. (b) the failure only appeared on buildfarm members running on ppc64 or s390x. I determined by examining assembly code that ppc64 uses about 3X as much stack per call level in this function as x86_64; probably s390x is similar. That was enough to overrun our default max_stack_depth on these architectures, even though the same case passed on the machines we'd tested on. (c) even with minimum max_stack_depth, the test passed using gcc but not clang. Again examining assembly code, gcc is smart enough to collapse the tail-recursion calls in findoprnd() into looping, causing the original test case's right-deep query tree to consume essentially zero stack space. clang doesn't do that, at least not on those arches at default optimization level. You can make gcc fail too with -O0. So it'd be good to verify on a few oddball platforms that Michael's new attempt is OK. It should theoretically work, but ... regards, tom lane