Re: New sessions on a database to be dropped consume 100% cpu

On Mon, Nov 26, 2018 at 1:12 AM Feike Steenbergen
<feikesteenbergen(at)gmail(dot)com> wrote:
> I created a backup (using pg_basebackup) from this cluster and had a look:
>
> name_to_be_dropped=# select bt_index_check('pg_catalog.pg_depend_depender_index');
> ERROR: cross page item order invariant violated for index "pg_depend_depender_index"
> DETAIL: Last item on page tid=(255,138) page lsn=33A5/F47BC3B0.

What does bt_index_parent_check() say? It might be different.

For some reason the pg_depend indexes are very well represented when
there is corruption at the storage level, so this doesn't necessarily
tell us much. I'd say that there is a very good chance that the
sibling page of block 255 contains a page image that isn't even a
B-Tree page at all (could be a heap block, could be garbage). I've
seen things like that in pg_depend index blocks quite a number of
times.

You could use a tool like pg_filedump to figure this out -- that
doesn't assume anything about the type of block it has been passed
(pg_hexedit would also work, and is helpful if you want a more visual
representation). You'd need to figure out the sibling block using
pageinspect, and from there you could use pg_filedump to dump that
block. This probably isn't going to help you to figure out what
happened, but it might.

--
Peter Geoghegan