On Wed, Feb 28, 2018 at 01:43:11PM -0800, Andres Freund wrote: > a significant number of times during investigations of bugs I wondered > whether running the cluster with various settings, or various tools > could've caused the issue at hand. Therefore I'd like to propose adding > a 'tainted' field to pg_control, that contains some of the "history" of > the cluster. Individual bits inside that field that I can think of right > now are: > - pg_resetxlog was used non-passively on cluster > - ran with fsync=off > - ran with full_page_writes=off > - pg_upgrade was used
What about: - pg_control versions used on this cluster (hopefully a full list..obviously not going back before PG11); - did recovery (you could use "needed recovery" instead, but then there's the question of how reliable that field would be); + or: timestamp of most recent recovery (attempt?) - index corruption detected (on system table?); Note that "CREATE IF NOT EXIST" doesn't avoid unique key errors on system tables, so it's not useful to log every ERROR on system tables. - page %u is uninitialized --- fixing - here's one I just dug up: ERROR: missing chunk number 0 for toast value 10270298 in pg_toast_2619 - XID wraparound? - autovacuum disabled? - checksum failue (in system relation?) - local_preload_libraries? - started in single user mode or with system indices disabled? - hit assertion or PANIC ?? - UPDATE/DELETE/INSERT on system table ? (or maintenance command like vacuum/analyze/cluster/reindex?) Justin