a thinko in b676ac443b6 - Mailing list pgsql-hackers

From Amit Langote
Subject a thinko in b676ac443b6
Date
Msg-id CA+HiwqEWd5B0-e-RvixGGUrNvGkjH2s4m95=JcwUnyV=f0rAKQ@mail.gmail.com
Whole thread Raw
Responses Re: a thinko in b676ac443b6  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List 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/

Attachment

pgsql-hackers by date:

Previous
From: Yugo NAGATA
Date:
Subject: Re: Fix around conn_duration in pgbench
Next
From: Greg Nancarrow
Date:
Subject: Re: Slim down integer formatting