public inbox for [email protected]  

help / color / mirror / Atom feed

From: Peter Geoghegan <[email protected]>
To: Erik Johnston <[email protected]>
Cc: [email protected]
Subject: Re: Corrupt btree index includes rows that don't match
Date: Wed, 9 Jul 2025 14:31:25 -0400
Message-ID: <CAH2-WzkbD3+=4NQJ9obiQZ6YfB0PHPwVEsrsOrTz2_5xk9V3Lg@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAPo1J60Vcu+5G0EvvAZtYgTn6U6ADij3aVJ8WFVz77jP+Bd_Tw@mail.gmail.com>
	<[email protected]>
	<CANzqJaAW2kwAyeJzboUCsbCpCk9ERDF1aZrW9OEa+DSqpPQxjA@mail.gmail.com>
	<CAPo1J60aoiwv=1HViWSiFEx9vpoj69cOfujCJRhy4Zjyw+QFaw@mail.gmail.com>
	<[email protected]>

On Wed, Jul 9, 2025 at 1:02 PM Erik Johnston <[email protected]> wrote:
> To recap: the situation is that, looking at our backup from 2025-06-26 via pageinspect, we have btree index rows which point to either non-existent heap TIDs, or to heap TIDs with data which does not correspond to the index row. In fact it looks like we have entire index pages which point only to non-existent heap TIDs.

This is a generic symptom of corruption. You can see this sort of
thing whenever (say) the storage lies about fsync having flushed
everything to disk. The index might still contain TIDs that point to
heap pages that existed before the crash, that didn't survive crash
recovery. It's quite likely that those same TIDs will be used for
wholly unrelated logical rows when the application inserts a little
more data.

> Empirically, and surprisingly to us, when one does a SELECT from an index entry that points to a non-existent TID, the index entry is quietly ignored.
>
> We therefore suspect that this index corruption has been present for some time (possibly years); more recently those non-existent heap TIDs have been recycled, and that is when we have noticed the effects of the problem.

That sounds plausible.

-- 
Peter Geoghegan

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Corrupt btree index includes rows that don't match
  In-Reply-To: <CAH2-WzkbD3+=4NQJ9obiQZ6YfB0PHPwVEsrsOrTz2_5xk9V3Lg@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox