Обсуждение: 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