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

On Mon, Sep 14, 2026, at 10:56 AM, Andres Freund wrote:
> 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?
>

Hey Andres, thanks for taking time to review this. The thread is moving to
the one started by the first person to report this issue [1].

> 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?

So, that I'm sure I understand the suggestion, you'd like to ensure that for any
heap or buffer-heap slot holding a tuple, slot->tts_tid == slot's stored
tuple->t_self. Correct?

I'll update the proposed patch set on the other thread [1]. Hope to see you
on that one so we can wrap this up and backpatch it.

> Greetings,
>
> Andres Freund

best.

-greg

[1] https://postgr.es/m/CAM6Zo8wZOLnCWRO_tuuXVX9J4N4JN6GsEnk8WJtT0%3D_0zy-1dw%40mail.gmail.com