Re: Why is parula failing? - Mailing list pgsql-hackers

From David Rowley
Subject Re: Why is parula failing?
Date
Msg-id CAApHDvp5BDe_O6udRSybXu0KWt5PKcvzpk8-+XHtKovdF3uo0A@mail.gmail.com
Whole thread Raw
In response to Re: Why is parula failing?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Why is parula failing?
List pgsql-hackers
On Sat, 30 Mar 2024 at 09:17, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I wrote:
> > I'd not looked closely enough at the previous failure, because
> > now that I have, this is well out in WTFF territory: how can
> > reltuples be greater than zero when relpages is zero?  This can't
> > be a state that autovacuum would have left behind, unless it's
> > really seriously broken.  I think we need to be looking for
> > explanations like "memory stomp" or "compiler bug".
>
> ... in connection with which, I can't help noticing that parula
> is using a very old compiler:
>
> configure: using compiler=gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-17)
>
> From some quick checking around, that would have to be near the
> beginning of aarch64 support in RHEL (Fedora hadn't promoted aarch64
> to a primary architecture until earlier that same year).  It's not
> exactly hard to believe that there were some lingering compiler bugs.
> I wonder why parula is using that when its underlying system seems
> markedly newer (the kernel at least has a recent build date).

It could be, but wouldn't the bug have to relate to the locking code
and be caused by some other backend stomping on the memory?
Otherwise, shouldn't it be failing consistently every run rather than
sporadically?

David



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Crash on UNION with PG 17
Next
From: "Tristan Partin"
Date:
Subject: [MASSMAIL]Silence Meson warning on HEAD