Re: wrong query results on bf leafhopper

Robins Tharakan <tharakan@gmail.com>

From: Robins Tharakan <tharakan@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: David Rowley <dgrowleyml@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org, "Tharakan, Robins" <tharar@amazon.com>
Date: 2025-06-03T01:15:51Z
Lists: pgsql-hackers
Hi,

On Thu, 29 May 2025 at 02:32, Andres Freund <andres@anarazel.de> wrote:

> On 2025-05-28 22:51:14 +0930, Robins Tharakan wrote:

> Recently leafhopper failed again on the same test. For now I've paused it.
> > To rule out the compiler (and its maturity on the architecture), I'll
> > upgrade
> > gcc (to nightly, or something more recent) and then re-enable to see if
> it
> > changes anything.
>
> +1 to a gcc upgrade, gcc 11 is rather old and out of upstream support.



Ack. I've updated leafhopper to gcc master. For now (to get the machine
green / running), I've disabled some flags, which I'll revisit in some time,
but hopefully that's not about compiler maturity - which is what I'm after
here.



> A kernel upgrade would be good too. My completely baseless gut feeling is
> that

some SIMD registers occassionally get corrupted, e.g. due to a kernel
> interrupt / context switch not properly storing & restoring them. Weirdly
> enought the instrumentation code is among the pieces of PG code most
> vulnerable to that because we mostly don't do enough auto-vectorizable
> math,
> but InstrEndLoop(), InstrStopNode() etc are trivially auto-vectorizable.
> I'm
> pretty sure I've previously analyzed problems around this, but don't
> remember
> the details (IA64 maybe?).
>

Fair point, I'll keep that option open. Originally, the machine was spun up
to
evaluate the graviton4 ec2 instance and I'd like to explore whether the
stock-kernel / kernel-updates are able to keep the instance green (and
resort
to updating the kernel only if I exhaust all other options - pg / compiler
etc.).

-
robins