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: pgsql-hackers@lists.postgresql.org, tharar@amazon.com
Date: 2024-03-20T23:36:02Z
Lists: pgsql-hackers
David Rowley <dgrowleyml@gmail.com> writes: > Is it worth running that animal with log_autovacuum_min_duration = 0 > so we can see what's going on in terms of auto-vacuum auto-analyze in > the log? Maybe, but I'm not sure. I thought that if parula were somehow hitting an ill-timed autovac/autoanalyze, it should be possible to make that reproducible by inserting "pg_sleep(60)" or so in the test script, to give the autovac daemon plenty of time to come around and do the dirty deed. No luck though --- the results didn't change for me. So now I'm not sure what is going on. Perhaps though it is autovacuum, and there's some environment-specific enabling condition that parula has and my machine doesn't (which could also help explain why no other animal is doing this). So yeah, if we could have log_autovacuum_min_duration = 0 perhaps that would yield a clue. 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