Re: Should setting TupleTableSlotOps get_heap_tuple=NULL break INSERT..ON CONFLICT DO UPDATE..RETURNING?
От | Andres Freund |
---|---|
Тема | Re: Should setting TupleTableSlotOps get_heap_tuple=NULL break INSERT..ON CONFLICT DO UPDATE..RETURNING? |
Дата | |
Msg-id | 20220929162229.ofghrmqliefjt6mv@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Should setting TupleTableSlotOps get_heap_tuple=NULL break INSERT..ON CONFLICT DO UPDATE..RETURNING? (Mark Dilger <mark.dilger@enterprisedb.com>) |
Ответы |
Re: Should setting TupleTableSlotOps get_heap_tuple=NULL break INSERT..ON CONFLICT DO UPDATE..RETURNING?
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: