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
