Re: [buildfarm related] Machines gcc experimental failed test_lfind

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: John Naylor <johncnaylorls(at)gmail(dot)com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [buildfarm related] Machines gcc experimental failed test_lfind
Date: 2025-11-26 15:51:12
Message-ID: 1587406.1764172272@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

John Naylor <johncnaylorls(at)gmail(dot)com> writes:
> On Wed, Nov 26, 2025 at 1:08 PM Hayato Kuroda (Fujitsu)
> <kuroda(dot)hayato(at)fujitsu(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message 河田達也 2025-11-26 16:00:41 Re: [Proposal] Adding TRIM_SPACE option to COPY
Previous Message Nathan Bossart 2025-11-26 15:50:58 Re: Remove unused struct fields