Hello Tom,
13.02.2023 21:39, Tom Lane wrote:
> Richard Guo <guofenglinux@gmail.com> writes:
>> On Sat, Feb 11, 2023 at 4:50 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I think it's time to clean this up by removing the rel from the
>>> planner data structures altogether. The attached passes check-world,
>>> and if it does trigger any problems I would say that's a clear
>>> sign of bugs elsewhere.
After this change the following query triggers an assert:
CREATE TABLE tt (tid integer PRIMARY KEY) PARTITION BY LIST (tid);
CREATE TABLE ttp PARTITION OF tt DEFAULT;
CREATE TABLE st (sid integer);
MERGE INTO tt USING st ON tt.tid = st.sid WHEN NOT MATCHED THEN INSERT
VALUES (st.sid);
...
#5 0x0000556fe84647eb in ExceptionalCondition
(conditionName=0x556fe8619a46 "operation != CMD_MERGE",
fileName=0x556fe8618b73 "createplan.c", lineNumber=7121) at assert.c:66
#6 0x0000556fe8126502 in make_modifytable (root=0x556fe945be40,
subplan=0x556fe9474420, operation=CMD_MERGE,
canSetTag=true, nominalRelation=1, rootRelation=1,
partColsUpdated=false, resultRelations=0x556fe9475bb0,
updateColnosLists=0x0, withCheckOptionLists=0x0,
returningLists=0x0, rowMarks=0x0, onconflict=0x0,
mergeActionLists=0x556fe9475c00, epqParam=0) at createplan.c:7121
#7 0x0000556fe811d479 in create_modifytable_plan (root=0x556fe945be40,
best_path=0x556fe9474a40)
at createplan.c:2820
#8 0x0000556fe811912a in create_plan_recurse (root=0x556fe945be40,
best_path=0x556fe9474a40, flags=1)
at createplan.c:530
#9 0x0000556fe8118ca8 in create_plan (root=0x556fe945be40,
best_path=0x556fe9474a40) at createplan.c:347
#10 0x0000556fe812d4fd in standard_planner (parse=0x556fe937c2d0,
query_string=0x556fe937b178 "MERGE INTO tt USING st ON tt.tid =
st.sid WHEN NOT MATCHED THEN INSERT VALUES (st.sid);",
cursorOptions=2048, boundParams=0x0) at planner.c:418
...
It seems that before e9a20e451 the other branch of the following
condition in make_modifytable() was executed:
/*
* If possible, we want to get the FdwRoutine from our
RelOptInfo for
* the table. But sometimes we don't have a RelOptInfo and
must get
* it the hard way. (In INSERT, the target relation is not
scanned,
* so it's not a baserel; and there are also corner cases for
* updatable views where the target rel isn't a baserel.)
*/
if (rti < root->simple_rel_array_size &&
root->simple_rel_array[rti] != NULL)
{
...
Best regards,
Alexander