Horton
Menu

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

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Noah Misch <noah@leadboat.com>
Cc: Maxim Boguk <maxim.boguk@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2022-02-02T21:01:49Z
Lists: pgsql-bugs 
Hi,

On 2022-01-28 18:34:18 -0800, Noah Misch wrote:
> If this bug is like the ones fixed between 14.0 and 14.1, the base backup
> and WAL won't help us, unfortunately.

FWIW: I've found that once one has identified a specific page / tuple that is
damaged, searching the WAL for the record causing the problem is really
helpful. Once that record is identified, the records from the transaction
logging the problematic WAL record(s) can often identify the concrete activity
at the time. And looking at the WAL records of concurrently running
transactions can often identify the concurrency problem.

It might not be worth it in this case (given we have a suspicion it's
18b87b20), but when you have a base backup from before the problem, and all
incremental WAL, just replaying forward incrementally and testing for the
problem can help narrow down problems a lot.

Greetings,

Andres Freund

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.