Re: [PATCH] Corruption Issue: Fix missing tts_tid in ExecForceStoreHeapTuple

On Sep 14, 2026, Greg Burd <greg(at)burd(dot)me> wrote:
> Done, so both checks now read zero when correct:

My AI harness noticed that v4-0001 still has the old ctid_matches join
returning 5, in both gist.sql and gist.out. It looks like the email and
attachment got out of sync.

> That is 0003. I put the check in table_tuple_lock() rather than
> heap_lock_tuple(), because heap_lock_tuple() is only reachable through
> the AM callback in heapam_handler.c, so one check at the boundary covers
> every AM and rejects the TID before any AM code runs.

This catches the reported (InvalidBlockNumber, 0), but
ItemPointerIsValid() only checks for a non-NULL pointer and ip_posid != 0.
For example, (InvalidBlockNumber, 1) still reaches the AM.

If the intended protection is specifically against passing P_NEW to
heap's ReadBuffer(), should this check be heap-side? A stronger generic
check would need a clearly stated table-AM invariant; the moved-partitions
marker is also an InvalidBlockNumber encoding with a nonzero offset.

Thanks,
Nik