Peter Geoghegan <p...@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
