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-04-02T00:11:33Z
Lists: pgsql-hackers
David Rowley <dgrowleyml@gmail.com> writes: > On Sat, 30 Mar 2024 at 09:17, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> ... 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) >> 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? Your guess is as good as mine ... but we still haven't seen this class of failure on any other animal, so the idea that it's strictly a chance timing issue is getting weaker all the time. 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