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

Hi,

On 2026-09-09 09:03:46 +0900, Michael Paquier wrote:
> On Tue, Sep 08, 2026 at 01:28:22PM -0400, Greg Burd wrote:
> > 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?

The assymmetry does suggest we should fix this. I'm somewhat sceptical that
it's sane to expect uses of ExecForceStoreHeapTuple() to actually have valid
tids, but ...

For a bit I was wondering whether the tuple's tid is actually the right one,
due to stuff like walking a HOT chain. But it seems we set both to the same
value (there's some subtleties around this nearby that I think I was confusing
this with, with the tid for a HOT updated needing to point to the root tuple
in some cases). I wonder if we ought to have an assertion for the two tids
being the same that, perhaps only on master?

Greetings,

Andres Freund