Message-ID: <36bee393-b351-16ac-93b2-d46d83637e45@gmail.com>
Date: Mon, 20 Feb 2023 14:00:00 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: Killing off removed rels properly
Content-Language: ru-RU
To: Tom Lane <tgl@sss.pgh.pa.us>, Richard Guo <guofenglinux@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
References: <229905.1676062220@sss.pgh.pa.us>
 <CAMbWs4_zhe22XqurMdcTx0PpSovHnCJSii3LXiutF_Hpdb9bxg@mail.gmail.com>
 <1343881.1676313553@sss.pgh.pa.us>
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <1343881.1676313553@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/36bee393-b351-16ac-93b2-d46d83637e45%40gmail.com>
Precedence: bulk

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