Horton
Menu

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

Noah Misch <noah@leadboat.com>

View thread
From: Noah Misch <noah@leadboat.com>
To: Maxim Boguk <maxim.boguk@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2022-01-29T02:34:18Z
Lists: pgsql-bugs

Attachments

On Fri, Jan 28, 2022 at 04:17:28PM +0200, Maxim Boguk wrote:
> On Fri, Jan 28, 2022 at 3:42 PM PG Bug reporting form <noreply@postgresql.org> wrote:
> > PostgreSQL version: 14.1

> Seems something broken in combination of HOT update and REINDEX
> CONCURRENTLY.

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.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix possible HOT corruption when RECENTLY_DEAD changes to DEAD while pruning.