Re: BUG #17268: Possible corruption in toast index after reindex index concurrently

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: alexey(dot)ermakov(at)dataegret(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>
Subject: Re: BUG #17268: Possible corruption in toast index after reindex index concurrently
Date: 2021-11-04 01:07:27
Message-ID: CAH2-Wznen2nOrUB32LrsuF4uGfDF1s_VZzDjhOYfLKo5H1g8Yw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Nov 3, 2021 at 3:26 AM PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
> it turns out one entry in toast index (?) was corrupted:
> select md5(body) from zz where id = ...;
> ERROR: missing chunk number 0 for toast value 4040061139 in
> pg_toast_2624976286
>
> According to "created_at" column in linked table row was created at
> "2021-11-02 13:04:22.192125", i.e. during reindex concurrently.

I wonder if it's a coincidence that that number (~4.04 billion) is not
that far from 2^32-1 (~4.294 billion).

Can you run amcheck? Perhaps the output of the following will be interesting:

create extension amcheck;
set client_min_messages=debug1;
select bt_index_check('pg_toast.pg_toast_2624976286_index', true);

(Couldn't hurt to try it, at least.)

> I'm wondering if it's known bug and how risky could it be to reindex toast's
> indexes. It was done automatically with tool which monitors indexes' bloat
> and index size reduced several times in this case.

If I had to guess, I'd guess that this is a new and unknown bug.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Geoghegan 2021-11-04 01:21:02 Re: ERROR: posting list tuple with 20 items cannot be split at offset 168
Previous Message Thomas Munro 2021-11-04 00:50:16 Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data