Обсуждение: BUG #17117: FailedAssertion at planner.c
The following bug has been logged on the website: Bug reference: 17117 Logged by: yaoguang chen Email address: cyg0810@gmail.com PostgreSQL version: 14beta2 Operating system: Linux supersix 5.4.0-39-generic #43-Ubuntu SMP Fri Description: PoC: CREATE TABLE v0 ( DEC TEXT , v3 INTEGER , v2 INTEGER , v1 INTEGER ) ; CREATE RULE v3 AS ON INSERT TO v0 DO INSTEAD VALUES ( - ( WITH v1 ( v2 ) AS ( SELECT - - 127 INTERSECT SELECT v1 + -1 FROM v0 ) SELECT ( SELECT ( SELECT ARRAY [ - 2147483647 , 63 , - 0 ] ) [ -2147483648 ] FROM v0 ) ) = - - 8 , - - 75 , 25 ) ; WITH NONE AS ( DELETE FROM v0 USING LATERAL ( SELECT * FROM ( SELECT DISTINCT * FROM v0 POSITION WHERE ( v1 , v3 ) = ANY ( SELECT v3 , v2 FROM v0 WHERE v2 < - 61 ) AND v3 <= 59 UNION ALL SELECT * FROM v0 TABLESAMPLE SYSTEM ( - 21 ) ) v2 WHERE v3 = v1 ) v2 RETURNING * ) INSERT INTO v0 VALUES ( - - - - - 16 , 127 , - - - - -128 ) ; crash log: 2021-07-20 11:46:09.117 CST [1788492] HINT: Future log output will go to log destination "csvlog". TRAP: FailedAssertion("!parse->rowMarks && parse->commandType == CMD_SELECT", File: "/home/supersix/fuzz/security/PostgreSQL/postgres/build/../src/backend/optimizer/plan/planner.c", Line: 1868, PID: 1788610) postgres: supersix x [local] INSERT(ExceptionalCondition+0xbb)[0x55b8f824cffb] postgres: supersix x [local] INSERT(+0x59480f)[0x55b8f7e5780f] postgres: supersix x [local] INSERT(subquery_planner+0xf63)[0x55b8f7e588e3] postgres: supersix x [local] INSERT(SS_process_ctes+0xb9)[0x55b8f7e65b39] postgres: supersix x [local] INSERT(subquery_planner+0x1f9)[0x55b8f7e57b79] postgres: supersix x [local] INSERT(standard_planner+0x165)[0x55b8f7e59535] postgres: supersix x [local] INSERT(pg_plan_query+0x6a)[0x55b8f7ff6eaa] postgres: supersix x [local] INSERT(pg_plan_queries+0x4d)[0x55b8f7ff6ffd] postgres: supersix x [local] INSERT(+0x7359f2)[0x55b8f7ff89f2] postgres: supersix x [local] INSERT(PostgresMain+0x1ae7)[0x55b8f7ffad57] postgres: supersix x [local] INSERT(+0x61671f)[0x55b8f7ed971f] postgres: supersix x [local] INSERT(PostmasterMain+0x1182)[0x55b8f7edc672] postgres: supersix x [local] INSERT(main+0x533)[0x55b8f798c133] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7fd1011130b3] postgres: supersix x [local] INSERT(_start+0x2e)[0x55b8f798c28e]
On Thu, 22 Jul 2021 at 23:23, PG Bug reporting form <noreply@postgresql.org> wrote: > CREATE TABLE v0 ( DEC TEXT , v3 INTEGER , v2 INTEGER , v1 INTEGER ) ; > CREATE RULE v3 AS ON INSERT TO v0 DO INSTEAD VALUES ( - ( WITH v1 ( v2 ) AS > ( SELECT - - 127 INTERSECT SELECT v1 + -1 FROM v0 ) SELECT ( SELECT ( SELECT > ARRAY [ - 2147483647 , 63 , - 0 ] ) [ -2147483648 ] FROM v0 ) ) = - - 8 , - > - 75 , 25 ) ; > WITH NONE AS ( DELETE FROM v0 USING LATERAL ( SELECT * FROM ( SELECT > DISTINCT * FROM v0 POSITION WHERE ( v1 , v3 ) = ANY ( SELECT v3 , v2 FROM v0 > WHERE v2 < - 61 ) AND v3 <= 59 UNION ALL SELECT * FROM v0 TABLESAMPLE SYSTEM > ( - 21 ) ) v2 WHERE v3 = v1 ) v2 RETURNING * ) INSERT INTO v0 VALUES ( - - - > - - 16 , 127 , - - - - -128 ) ; This can be simplified to: create table t1 (a int); create rule t1_rule as on insert to t1 do instead values(1); with cte as (delete from v0 returning *) insert into v0 values(2); I'm unsure if parse->hasModifyingCTE is not being set properly and that's causing PlannerGlobal.parallelModeOK to be set incorrectly in standard_planner or if we should just be never setting anything to parallelModeOK that's not parse->querySource == QSRC_ORIGINAL. I might not have enough time to look into this further, so if anyone else is lurking, feel free. David
On Fri, 23 Jul 2021 at 00:28, David Rowley <dgrowleyml@gmail.com> wrote: > This can be simplified to: > > create table t1 (a int); > create rule t1_rule as on insert to t1 do instead values(1); > with cte as (delete from v0 returning *) insert into v0 values(2); That was meant to be: create table t1 (a int); create rule t1_rule as on insert to t1 do instead values(1); with cte as (delete from v0 returning *) insert into t1 values(2); > I'm unsure if parse->hasModifyingCTE is not being set properly and > that's causing PlannerGlobal.parallelModeOK to be set incorrectly in > standard_planner or if we should just be never setting anything to > parallelModeOK that's not parse->querySource == QSRC_ORIGINAL. I think the hasModifyingCTE going missing is the problem here. What seems to be going on is that we have a DO INSTEAD rule to change an INSERT on t1 to a SELECT, (the "values(1)" clause). When we find the INSERT in the query with the CTE, we change the parse to the rewritten one due to the DO INSERT rule so that the entire query becomes: with cte as (delete from v0 returning *) values(1); however, along the way when replacing the parse after copying in the CTEs from the original, we forget to also set hasModifyingCTE if it was set in the original query. I think the fix is what I've attached, however, I don't often get a chance to look at the rewriter in detail, so I'd be happy if someone else took a look to see if they agree. David
Вложения
David Rowley <dgrowleyml@gmail.com> writes: > On Fri, 23 Jul 2021 at 00:28, David Rowley <dgrowleyml@gmail.com> wrote: >> I'm unsure if parse->hasModifyingCTE is not being set properly and >> that's causing PlannerGlobal.parallelModeOK to be set incorrectly in >> standard_planner or if we should just be never setting anything to >> parallelModeOK that's not parse->querySource == QSRC_ORIGINAL. > I think the hasModifyingCTE going missing is the problem here. I think this is a dup of the ongoing discussion at https://www.postgresql.org/message-id/flat/CAJcOf-fAdj=nDKMsRhQzndm-O13NY4dL6xGcEvdX5Xvbbi0V7g@mail.gmail.com The thing that's stalled that discussion is disagreement over whether it's necessary to make a bigger change than what you have here. regards, tom lane