Re: Why is parula failing?
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Tharakan, Robins" <tharar@amazon.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2024-04-01T23:28:40Z
Lists: 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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Revert "Temporarily install debugging in partition_prune test"
- ec1a405adc24 17.0 landed
-
Temporarily install debugging in partition_prune test
- 1db689715d44 17.0 landed
-
Review wording on tablespaces w.r.t. partitioned tables
- a0390f6ca6c7 17.0 cited