Re: GIN page deletion and page recycling bugs

> On 20 Aug 2026, at 20:52, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> Attached patch fixes the bug as outlined. It would be good to get a
> GIN expert to review this.

Hi Peter,

I don't think I qualify as a GIN expert, but both bugs and the proposed
fixes seem fairly clear to me. PFA a three-patch version. The first
two patches are intended for backpatching; the third one is for master
only.

Your patch looks correct to me. It might be worth covering the
incomplete target page separately: the test currently covers deletion
after an incomplete left sibling. I would also avoid the
expected count of 39879. Comparing the index result with a sequential
scan would express the correctness property more directly and tie the
test less closely to the physical page layout. This already failed in
Linux Autoconf CI, which produced 36449 instead of 39879 [0].

In the longer term, a heap-all-indexed check for GIN in amcheck would
be a better oracle for bugs like this.

The second patch follows your back-branch proposal and emits
XLOG_GIST_PAGE_REUSE when GIN reuses a deleted page. The reproducer now
expects replay to cancel the standby scan. Without the fix I get 7860
rows from the GIN scan instead of 112338 from the sequential scan; with
the fix the recovery conflict is raised as expected.

The third patch addresses one related old issue on master. GIN still
stores its deletion horizon as a 32-bit XID. After about 2 billion XIDs
a deleted page can be considered non-recyclable for the following
2-billion-XID window. GiST and nbtree were changed to store full XIDs in
6655a7299d8 and e5d8a999030. I mentioned the same problem in GIN in 2019
[1], but apparently we never followed up. The new representation has a
page flag, so pg_upgraded indexes keep the old conservative behavior for
their old deleted pages. I do not propose this part for backpatching.

Thanks!

Best regards, Andrey Borodin.

[0] https://github.com/x4m/postgres_g/actions/runs/32563364088/job/97008437447
[1] https://www.postgresql.org/message-id/AFDDB5CC-CC41-4E73-AD92-09AF4BDE926F%40yandex-team.ru