Re: BUG #17245: Index corruption involving deduplicated entries

On Thu, Oct 28, 2021 at 12:34 AM Kamigishi Rei <iijima(dot)yun(at)koumakan(dot)jp> wrote:
> > Just one more request: Can I have some more pages from the same
> > indexes? You have already provided me with
> > "mediawiki.transcode_key_idx.block1.page". But could you now also
> > provide me with blocks 2, 8, and 16 from the same index? This is a
> > pretty random choice. I just want to see if they all contain corrupt
> > posting list tuples, like page 1 (I suspect that they all will).
>
> Despatched in a separate e-mail along with page 0 from "mediawiki.page"
> requested in your follow-up message.

Thanks!

> > Note that I pushed some additional hardening for posting list splits
> > today. This will be in Postgres 14.1. The new code won't fix the
> > problem, but it will detect problems earlier, limiting the damage.
>
> Would you recommend applying the patch to my ‘production’ instance or
> should keep it as is to see if that undetectable corruption case
> (leading to weird SELECT etc. results) shows up again?

Yes, that's definitely a good idea, if you have a convenient way to
build the REL_14_STABLE branch from source easily (or you can just
wait for 14.1). The new defensive checks will at least give you more
information about any problems that happen in the B-Tree code. It will
also limit possible harms.

It would be great from my point of view if you had the extra checks
today, because it might lead to better information about what's really
going on here.

> CREATE INDEX was run during the import of the 13.3-generated dump; there
> were no schema changes since. The transcode table gets updated every
> time an audio file is uploaded, which happened quite a few times since
> the upgrade.

Got it. Thanks.

--
Peter Geoghegan