Re: Intermittent buildfarm failures on wrasse

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>, Noah Misch <noah@leadboat.com>
Cc: Peter Geoghegan <pg@bowt.ie>, David Rowley <dgrowleyml@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-04-14T01:51:12Z
Lists: pgsql-hackers
Hi,

Noah, any chance you could enable log_autovacuum_min_duration=0 on
wrasse?


On 2022-04-13 21:23:12 -0400, Tom Lane wrote:
> I'm still suspicious of the pgstat changes, though.  I checked into
> things here by doing
> 
> 	initdb
> 	edit postgresql.conf to set log_autovacuum_min_duration = 0
> 	pg_ctl start && make installcheck-parallel
> 
> and what I see is that the first reported autovacuum activity begins
> exactly one minute after the postmaster starts, which is what I'd
> expect given the autovacuum naptime rules.

It'd not necessarily have to be autovacuum. A CREATE INDEX or VACUUM
using parallelism, could also cause this, I think. It'd be a narrow
window, of course...

Does sparc have wider alignment rules for some types? Perhaps that'd be
enough to put some tables to be sufficiently larger to trigger parallel
vacuum?

Greetings,

Andres Freund



Commits

  1. Repurpose PROC_COPYABLE_FLAGS as PROC_XMIN_FLAGS

  2. Tighten ComputeXidHorizons' handling of walsenders.

  3. Adjust VACUUM's removable cutoff log message.

  4. Temporarily add some probes of tenk1's relallvisible in create_index.sql.

  5. Set synchronous_commit=on in test_setup.sql.

  6. Rearrange core regression tests to reduce cross-script dependencies.

  7. snapshot scalability: Don't compute global horizons while building snapshots.