Re: [buildfarm related] Machines gcc experimental failed test_lfind
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: John Naylor <johncnaylorls@gmail.com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
"pgsql-hackers@lists.postgresql.org"
<pgsql-hackers@lists.postgresql.org>
Date: 2025-11-26T15:51:12Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Optimize vector8_has_le() on AArch64.
- f8f4afe751fc 19 (unreleased) cited
-
Properly fix AVX-512 CRC calculation bug
- 43da394304fb 18.0 cited
John Naylor <johncnaylorls@gmail.com> writes: > On Wed, Nov 26, 2025 at 1:08 PM Hayato Kuroda (Fujitsu) > <kuroda.hayato@fujitsu.com> wrote: >> Also, what should we do for nightly-built compilers? Will we fix tests or codes for them? > We might ask ourselves how often these have resulted in > forward-looking fixes for our code, weighed against spurious failures > and compiler bugs. If a problem is being observed only on animals with experimental compilers, it's almost surely a compiler bug and not something we should spend time on. In this case, the failure is in test code that hasn't changed in several years, making it even less likely that we broke it. I'm not really thrilled that toolchains like these are being run as normal buildfarm animals. Even with the "experimental" annotation, there's too much chance that PG hackers will spend time analyzing issues that aren't ours. I do realize that there's value in this sort of testing, I just wish the results were more clearly identified as "probably not our problem". regards, tom lane