Re: Why is parula failing?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: "Tharakan, Robins" <tharar@amazon.com>,
"pgsql-hackers@lists.postgresql.org"
<pgsql-hackers@lists.postgresql.org>
Date: 2024-03-29T20:17:16Z
Lists: pgsql-hackers
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). regards, tom lane
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