Re: New sessions on a database to be dropped consume 100% cpu - Mailing list pgsql-bugs

From Peter Geoghegan
Subject Re: New sessions on a database to be dropped consume 100% cpu
Date
Msg-id CAH2-Wzmtcq5etZKiLA3JmD2v1vQkhNsquiY1AP3ZwFLEQJnjgQ@mail.gmail.com
Whole thread Raw
In response to Re: New sessions on a database to be dropped consume 100% cpu  (Feike Steenbergen <feikesteenbergen@gmail.com>)
List pgsql-bugs
On Mon, Nov 26, 2018 at 1:12 AM Feike Steenbergen
<feikesteenbergen@gmail.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


pgsql-bugs by date:

Previous
From: Thomas Munro
Date:
Subject: Re: BUG #15520: PAM authentication + domain socket -> DNS query forsymbolic hostname [local]
Next
From: PG Bug reporting form
Date:
Subject: BUG #15523: \df command not working in psql 10.4 postgres 11.1 version