Re: GiST wal_consistency_checking issue

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: GiST wal_consistency_checking issue
Date: 2026-08-16 06:31:34
Message-ID: aoFZRg8Y-lrdN8i1@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Aug 15, 2026 at 08:15:23PM -0400, Peter Geoghegan wrote:
> We already have test coverage for LP_DEAD marking GiST index tuples in
> src/test/modules/index/specs/killtuples.spec (plus coverage for all
> other index AMs that support this optimization). What we lack is test
> coverage for the code that deals with subsequent deletion of those
> LP_DEAD-marked tuples by gistprunepage (and so gistRedoDeleteRecord,
> its REDO routine, also isn't tested).
>
> Attached v2 adds this missing test coverage.

Short runtime, that works. And also confirmed that without your
suggested fix:
2026-08-16 15:24:25.504 JST startup[48936] FATAL: inconsistent page
found, rel 1663/16384/16526, forknum 0, blkno 3
2026-08-16 15:24:25.504 JST startup[48936] CONTEXT: WAL redo at
0/2132BD18 for Gist/DELETE: delete: snapshotConflictHorizon 0, nitems:
162, isCatalogRel F; blkref #0: rel 1663/16384/16526, blk 3 FPW

I have looked as well at the patch, and that seems sensible to remove
the delete markers, I was surprised to see that we do nothing with
them, with traces of these macros removed in commits as old as
68446b2c87a2. Leaving pageinspect as you are suggesting is fine for
existing on-disk data.

So that WFM.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-08-16 06:45:08 Re: [BUG] hstore integer overflow when constructing large values
Previous Message Tatsuya Kawata 2026-08-16 06:27:43 [PATCH] Fix compilation of nodeMergejoin.c with EXEC_MERGEJOINDEBUG