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-03-27T09:35:19Z
Lists: pgsql-hackers
On Wed, 27 Mar 2024 at 18:28, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > David Rowley <dgrowleyml@gmail.com> writes: > > Unfortunately, REL_16_STABLE does not have the additional debugging, > > so don't get to know what reltuples was set to. > > Let's wait a bit to see if it fails in HEAD ... but if not, would > it be reasonable to back-patch the additional debugging output? I think REL_16_STABLE has told us that it's not an auto-vacuum issue. I'm uncertain what a few more failures in master will tell us aside from if reltuples == 48 is consistent or if that value is going to fluctuate. Let's give it a week and see if it fails a few more times. 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