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