a thinko in b676ac443b6
От | Amit Langote |
---|---|
Тема | a thinko in b676ac443b6 |
Дата | |
Msg-id | CA+HiwqEWd5B0-e-RvixGGUrNvGkjH2s4m95=JcwUnyV=f0rAKQ@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: a thinko in b676ac443b6
|
Список | pgsql-hackers |
Hi, I noticed $subject while rebasing my patch at [1] to enable batching for the inserts used in cross-partition UPDATEs. b676ac443b6 did this: - resultRelInfo->ri_PlanSlots[resultRelInfo->ri_NumSlots] = - MakeSingleTupleTableSlot(planSlot->tts_tupleDescriptor, - planSlot->tts_ops); ... + { + TupleDesc tdesc = CreateTupleDescCopy(slot->tts_tupleDescriptor); + + resultRelInfo->ri_Slots[resultRelInfo->ri_NumSlots] = + MakeSingleTupleTableSlot(tdesc, slot->tts_ops); ... + resultRelInfo->ri_PlanSlots[resultRelInfo->ri_NumSlots] = + MakeSingleTupleTableSlot(tdesc, planSlot->tts_ops); I think it can be incorrect to use the same TupleDesc for both the slots in ri_Slots (for ready-to-be-inserted tuples) and ri_PlanSlots (for subplan output tuples). Especially if you consider what we did in 86dc90056df that was committed into v14. In that commit, we changed the way a subplan under ModifyTable produces its output for an UPDATE statement. Previously, it would produce a tuple matching the target table's TupleDesc exactly (plus any junk columns), but now it produces only a partial tuple containing the values for the changed columns. So it's better to revert to using planSlot->tts_tupleDescriptor for the slots in ri_PlanSlots. Attached a patch to do so. -- Amit Langote EDB: http://www.enterprisedb.com [1] https://commitfest.postgresql.org/33/2992/
Вложения
В списке pgsql-hackers по дате отправления: