Hi,
On 2018-02-28 16:16:53 -0600, Justin Pryzby wrote:
Unfortunately your list seems to raise the bar to a place I don't see us
going soon :(
> - pg_control versions used on this cluster (hopefully a full list..obviously
> not going back before PG11);
That needs arbitrary much space, that's not feasible for
pg_control. Needs to be <= 512 bytes
> - 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?)
What'd that be useful for?
> - 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.
I don't think we have a easy way to diagnose this specifically enough
> - page %u is uninitialized --- fixing
Doesn't really indicate a bug / problem.
> - here's one I just dug up: ERROR: missing chunk number 0 for toast value 10270298 in pg_toast_2619
Hm.
> - XID wraparound?
why?
> - autovacuum disabled?
why?
> - checksum failue (in system relation?)
Hm.
> - local_preload_libraries?
Hm?
> - started in single user mode or with system indices disabled?
why?
> - hit assertion or PANIC ??
We certainly don't write to persistent data in those case.
> - UPDATE/DELETE/INSERT on system table ? (or maintenance command like
> vacuum/analyze/cluster/reindex?)
Hm, the former I could see some use for, but it might end up being
pretty ugly locking and layering wise.
Greetings,
Andres Freund
