| 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
| 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 |