Re: Postgres crashes at memcopy() after upgrade to PG 13.

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Avinash Kumar <avinash(dot)vallarapu(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Postgres crashes at memcopy() after upgrade to PG 13.
Date: 2021-03-16 18:31:34
Message-ID: CAH2-WznTGpkc3QPCAzr89H=Hxjqp1nE-O8Z67khfwbFnU1a9cA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Tue, Mar 16, 2021 at 11:20 AM Avinash Kumar
<avinash(dot)vallarapu(at)gmail(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2021-03-16 19:00:55 Re: Binary encoding of timetz type
Previous Message Ruslan 2021-03-16 18:30:39 Binary encoding of timetz type

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2021-03-16 18:40:20 Re: pg_amcheck contrib application
Previous Message Mark Dilger 2021-03-16 18:24:33 Re: pg_amcheck contrib application