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
