Re: Killing off removed rels properly

Hello Tom,

13.02.2023 21:39, Tom Lane wrote:
> Richard Guo <guofenglinux(at)gmail(dot)com> writes:
>> On Sat, Feb 11, 2023 at 4:50 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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