Re: BUG #17386: btree index corruption after reindex concurrently on write heavy table

On Fri, Jan 28, 2022 at 6:34 PM Noah Misch <noah(at)leadboat(dot)com> wrote:
> Agreed. Can you create a self-contained test case, perhaps by adapting
> contrib/amcheck/t/002_cic.pl? If this bug is like the ones fixed between 14.0
> and 14.1, the base backup and WAL won't help us, unfortunately. The transient
> states are what matter. I did try modifying the test to have elements of your
> scenario, including HOT updates, KEY SHARE locks, and frozen tuples. That
> didn't reproduce the bug. I'm attaching what I tried.

If I had to guess, then I'd guess that this has something to do with
orphaned HOT chains, like those we saw in the bug report that led to
bugfix commit 18b87b20 (which is in 14.2 but not 14.1). I could easily
be wrong about that, so take it with a grain of salt. I find it a
little suspicious that we're hearing about a REINDEX CONCURRENTLY
problem in Postgres 14, which is much less mature than Postgres 12
(where REINDEX CONCURRENTLY first appeared).

--
Peter Geoghegan