| From: | John Naylor <johncnaylorls(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Re-add recently-removed tests for ltree and intarray |
| Date: | 2026-05-15 02:47:04 |
| Message-ID: | CANWCAZZTa8oVUvUN_-ueySDRjCqNNWAr5Mb4D2ARbmA2LiBPAw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, May 15, 2026 at 9:09 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> (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.
FWIW, I tried to reproduce with the former new tests un-reverted, and
didn't see stack overflow on the following, so unless I fat-fingered
that I wonder if there's something more specific on the previously
failing members:
ppc64le / gcc 8.5 / Linux kernel 4.18
S390X / gcc 13.3 / Linux kernel 6.8
--
John Naylor
Amazon Web Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-05-15 02:49:38 | Re: Re-add recently-removed tests for ltree and intarray |
| Previous Message | Tom Lane | 2026-05-15 02:09:29 | Re: Re-add recently-removed tests for ltree and intarray |