Re: Intermittent buildfarm failures on wrasse

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Andres Freund <andres@anarazel.de>, Noah Misch <noah@leadboat.com>, David Rowley <dgrowleyml@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-04-14T22:23:38Z
Lists: pgsql-hackers
Peter Geoghegan <pg@bowt.ie> writes:
> Have you looked at the autovacuum log output in more detail?

I don't think there's anything to be learned there.  The first autovacuum
in wrasse's log happens long after things went south:

2022-04-14 22:49:15.177 CEST [9427:1] LOG:  automatic vacuum of table "regression.pg_catalog.pg_type": index scans: 1
	pages: 0 removed, 49 remain, 49 scanned (100.00% of total)
	tuples: 539 removed, 1112 remain, 0 are dead but not yet removable
	removable cutoff: 8915, older by 1 xids when operation ended
	index scan needed: 34 pages from table (69.39% of total) had 1107 dead item identifiers removed
	index "pg_type_oid_index": pages: 14 in total, 0 newly deleted, 0 currently deleted, 0 reusable
	index "pg_type_typname_nsp_index": pages: 13 in total, 0 newly deleted, 0 currently deleted, 0 reusable
	avg read rate: 0.000 MB/s, avg write rate: 0.000 MB/s
	buffer usage: 193 hits, 0 misses, 0 dirtied
	WAL usage: 116 records, 0 full page images, 14113 bytes
	system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s

If we captured equivalent output from the manual VACUUM in test_setup,
maybe something could be learned.  However, it seems virtually certain
to me that the problematic xmin is in some background process
(eg autovac launcher) and thus wouldn't show up in the postmaster log,
log_line_prefix or no.

			regards, tom lane



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.