Re: gistkillitems can LP_DEAD-mark the wrong tuples on a rescan - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: gistkillitems can LP_DEAD-mark the wrong tuples on a rescan
Date
Msg-id CF2BF1B3-5B0A-43F1-80BD-4E8E3D4111A5@yandex-team.ru
Whole thread
In response to Re: gistkillitems can LP_DEAD-mark the wrong tuples on a rescan  (Andrey Borodin <x4mmm@yandex-team.ru>)
Responses Re: [PATCH] Doc: document standard_conforming_strings dump/restore incompatibility
Re: gistkillitems can LP_DEAD-mark the wrong tuples on a rescan
List pgsql-hackers

> On 16 Aug 2026, at 15:00, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
>
> wal_consistency_checking

Sorry, the message I just sent was intended for the nearby
"GiST wal_consistency_checking issue" thread.  Since I have already bumped
this thread, let me reply to Peter's report too.

Looking back at Kirill's thread that led to 9c9ddf109 [0], I wrote:

> Sorry, I meant so->curBlkno and so->numKilled are semantically correlated.
> But it's difficult to assign them together and this does not worth
> refactoring.

That did not age well.  This bug is exactly the failure mode that observation
anticipated, so I no longer think that these fields should remain
independent.

Calling gistkillitems() from gistrescan() and gistendscan() looks like the
right fix.  Longer term, I think the block number, page LSN and
killed offsets should form one kill-state object, initialized only for a
leaf page and invalidated as a unit.  Visiting an internal page should never
replace the identity of the page to which pending kill offsets belong.

It also seems worth making the leaf-page check effective in non-assert
builds.


Best regards, Andrey Borodin.


[0] https://www.postgresql.org/message-id/flat/CALdSSPgZWX_D8%2BFx4YQqRN5eW5iSx_rJdqQhCfdWTvqKXVfJ4w%40mail.gmail.com
[1] https://www.postgresql.org/message-id/flat/lxzj26ga6ippdeunz6kuncectr5gfuugmm2ry22qu6hcx6oid6%40lzx3sjsqhmt6


pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: Request to expedite CommitFest account cool-off period
Next
From: Tom Lane
Date:
Subject: Residual tsquery cleanups