Re: ExecForceStoreHeapTuple() loses tts_tid, so ORDER BY-op index scans project an invalid ctid

On Tue, Sep 08, 2026 at 01:28:22PM -0400, Greg Burd wrote:
> ExecForceStoreHeapTuple() does not set slot->tts_tid when the target
> slot is a TTS_IS_BUFFERTUPLE slot. Any plan that re-stores a heap tuple
> through it and then projects ctid therefore gets (4294967295,0) instead
> of the row's real heap TID.

Oops.

My question would be what kind of testing you have done to spot that..

> ExecClearTuple() reaches tts_buffer_heap_clear(), which does
> ItemPointerSetInvalid(&slot->tts_tid). The tuple is then copied in, but
> tts_tid is left invalid. The sibling path, ExecStoreHeapTuple() ->
> tts_heap_store_tuple() — *does* slot->tts_tid = tuple->t_self, so this
> reads as a plain asymmetry rather than an intentional choice.

That's strange. Once thing that I can see why scanning this file is
the same code pattern in tts_buffer_heap_copyslot(), where a slot is
similarly cleared in a copy-paste fashion.

Andres?
--
Michael