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
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 |