On Tue, Mar 16, 2021 at 11:20 AM Avinash Kumar <avinash.vallar...@gmail.com> wrote: > I can share any detail that would help here.
I would like to know what you see when you run a slightly modified version of the same amcheck query. The same query as before, but with the call to bt_index_parent_check() replaced with a call to bt_index_check(). Can you do that, please? This is what I mean: SELECT bt_index_check(index => c.oid, heapallindexed => true), c.relname, c.relpages FROM pg_index i JOIN pg_opclass op ON i.indclass[0] = op.oid JOIN pg_am am ON op.opcmethod = am.oid JOIN pg_class c ON i.indexrelid = c.oid JOIN pg_namespace n ON c.relnamespace = n.oid WHERE am.amname = 'btree' -- Don't check temp tables, which may be from another session: AND c.relpersistence != 't' -- Function may throw an error when this is omitted: AND c.relkind = 'i' AND i.indisready AND i.indisvalid ORDER BY c.relpages DESC; The error that you reported was a cross-level invariant violation, from one of the tests that bt_index_parent_check() performs but bt_index_check() does not perform (the former performs checks that are a superset of the latter). It's possible that we'll get a more interesting error message from bt_index_check() here, because it might go on for a bit longer -- it might conceivably reach a corrupt posting list tuple on the leaf level, and report it as such. Of course we don't see any corruption in the index that you had the crash with at all, but it can't hurt to do this as well -- just in case the issue is transient or something. Thanks -- Peter Geoghegan
