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 →
  1. Revert "Temporarily install debugging in partition_prune test"

  2. Temporarily install debugging in partition_prune test

  3. Review wording on tablespaces w.r.t. partitioned tables