Hi, On 2022-09-29 09:04:42 -0700, Mark Dilger wrote: > Per the documentation in TupleTableSlotOps, an AM can choose not to supply a > get_heap_tuple function, and instead set this field to NULL. Doing so > appears to almost work, but breaks the xmin and xmax returned by a > INSERT..ON CONFLICT DO UPDATE..RETURNING. In particular, the call chain > ExecOnConflictUpdate -> ExecUpdate -> table_tuple_update seems to expect > that upon return from table_tuple_update, the slot will hold onto a copy of > the updated tuple, including its header fields. This assumption is inherent > in how the slot is later used by the destination receiver. But for TAMs > which do not keep a copy heaptuple of their own, the slot will only have > copies of (tts_tupleDescriptor, tts_values, tts_isnull) to use to form up a > tuple when the receiver asks for one, and that formed up MinimalTuple won't > be preceded by any meaningful header.
I would assume that this can be avoided by the tuple slot implementation, but without seeing what precisely you did in your pile slot... Greetings, Andres Freund
