From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Subject: | a thinko in b676ac443b6 |
Date: | 2021-07-27 02:28:00 |
Message-ID: | CA+HiwqEWd5B0-e-RvixGGUrNvGkjH2s4m95=JcwUnyV=f0rAKQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
Attachment | Content-Type | Size |
---|---|---|
b676ac443b6-thinko-fix.patch | application/octet-stream | 1.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Nancarrow | 2021-07-27 02:28:22 | Re: Slim down integer formatting |
Previous Message | Yugo NAGATA | 2021-07-27 02:02:47 | Re: Fix around conn_duration in pgbench |