Обсуждение: BUG #17097: FailedAssertion at initsplan.c

The following bug has been logged on the website:

Bug reference:      17097
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:

run the following sql command through client and the PostgreSQL database
process will crash:

CREATE TABLE v0 ( v1 FLOAT ) ; WITH v1 AS ( INSERT INTO v0 VALUES ( - - - 98
) , ( - 84 ) , ( - - - - - - - 96 ) , ( - - - 79 ) , ( - - 60 ) , ( - - - -1
) , ( - - - 67 ) , ( - - - -2147483648 ) RETURNING * ) SELECT * FROM v0 ;
 ALTER TABLE v0 NO FORCE ROW LEVEL SECURITY ;
 CREATE TEMP VIEW v0 AS SELECT * FROM v0 WHERE v1 IN ( SELECT v1 FROM v0
WHERE ( v1 , v1 ) < ANY ( SELECT v1 XMLPARSE , v1 FROM v0 WHERE v1 < - - 10
) AND v1 <= - - - 85 UNION ALL SELECT v1 FROM LATERAL COALESCE ( -1 , 27 , 0
, NULL , - - 77 ) v1 WHERE v1 IN ( SELECT * FROM v0 WHERE - - - - 22 IN (
CASE WHEN v1 >= - - 12 THEN ( - - 61 * v1 ) ELSE - - - -32768 END , ( v1 +
v1 ) / - -128 , - - - 84 ) ORDER BY v1 ) ) ;
 SELECT * FROM ( SELECT * FROM v0 v1 WHERE v1 < - - - - - - - 0 AND v1 IN (
- - - - 48 , - - - - 92 ) UNION ALL SELECT * FROM v0 v1 GROUP BY ROLLUP ( v1
, v1 ) , GROUPING SETS ( ROLLUP ( - - - - -1 - - - - 89 , v1 ) , CUBE ( ( v1
+ - - - 0 ) , ( v1 + - - 0 ) ) ) ) v1 ;
 DROP CONVERSION IF EXISTS v0 ;
 CREATE TABLE v2 ( v6 INT , v5 TIMESTAMP [ ] UNIQUE , v4 INT , v3 INT UNIQUE
)


log:

TRAP: FailedAssertion("false", File:
"/home/supersix/fuzz/security/PostgreSQL/postgres/build/../src/backend/optimizer/plan/initsplan.c",
Line: 377, PID: 1946457)postgres: supersix x 127.0.0.1(61220)
SELECT(ExceptionalCondition+0xbb)[0x556925fe9ffb]postgres: supersix x
127.0.0.1(61220) SELECT(+0x582528)[0x556925be2528]
postgres: supersix x 127.0.0.1(61220)
SELECT(query_planner+0xde)[0x556925be72fe]
postgres: supersix x 127.0.0.1(61220) SELECT(+0x591ea5)[0x556925bf1ea5]
postgres: supersix x 127.0.0.1(61220)
SELECT(subquery_planner+0xf63)[0x556925bf58e3]
postgres: supersix x 127.0.0.1(61220) SELECT(+0x5aff3e)[0x556925c0ff3e]
postgres: supersix x 127.0.0.1(61220) SELECT(+0x5afdc4)[0x556925c0fdc4]
postgres: supersix x 127.0.0.1(61220)
SELECT(plan_set_operations+0x3f2)[0x556925c10ee2]
postgres: supersix x 127.0.0.1(61220) SELECT(+0x591228)[0x556925bf1228]
postgres: supersix x 127.0.0.1(61220)
SELECT(subquery_planner+0xf63)[0x556925bf58e3]
postgres: supersix x 127.0.0.1(61220) SELECT(+0x53e2a9)[0x556925b9e2a9]
postgres: supersix x 127.0.0.1(61220)
SELECT(make_one_rel+0x1ec)[0x556925ba2d3c]
postgres: supersix x 127.0.0.1(61220)
SELECT(query_planner+0x15b)[0x556925be737b]
postgres: supersix x 127.0.0.1(61220) SELECT(+0x591ea5)[0x556925bf1ea5]
postgres: supersix x 127.0.0.1(61220)
SELECT(subquery_planner+0xf63)[0x556925bf58e3]
postgres: supersix x 127.0.0.1(61220) SELECT(+0x53e2a9)[0x556925b9e2a9]
postgres: supersix x 127.0.0.1(61220) SELECT(+0x53d472)[0x556925b9d472]
postgres: supersix x 127.0.0.1(61220)
SELECT(make_one_rel+0x1ec)[0x556925ba2d3c]
postgres: supersix x 127.0.0.1(61220)
SELECT(query_planner+0x15b)[0x556925be737b]
postgres: supersix x 127.0.0.1(61220) SELECT(+0x591ea5)[0x556925bf1ea5]
postgres: supersix x 127.0.0.1(61220)
SELECT(subquery_planner+0xf63)[0x556925bf58e3]
postgres: supersix x 127.0.0.1(61220)
SELECT(standard_planner+0x165)[0x556925bf6535]
postgres: supersix x 127.0.0.1(61220)
SELECT(pg_plan_query+0x6a)[0x556925d93eaa]
postgres: supersix x 127.0.0.1(61220)
SELECT(pg_plan_queries+0x4d)[0x556925d93ffd]
postgres: supersix x 127.0.0.1(61220) SELECT(+0x7359f2)[0x556925d959f2]

John Naylor <john.naylor@enterprisedb.com> writes:
> The reproducer I shared stopped working at 7266d0997dd2a (Allow
> functions-in-FROM to be pulled up if they reduce to constants). I'll dig
> deeper a bit later unless someone beats me to it.

Sounds like it's my fault then :-(.  I'll look closer in a bit.

            regards, tom lane

John Naylor <john.naylor@enterprisedb.com> writes:
> If it saves you some time, the assert happens here in
> replace_vars_in_jointree():

> case RTE_JOIN:
> case RTE_CTE:
> case RTE_NAMEDTUPLESTORE:
> case RTE_RESULT:
> /* these shouldn't be marked LATERAL */
> Assert(false);
> break;

> where the plan has RTE_RESULT

Ah.  When converting the FUNCTION RTE to a dummy RESULT,
we must clear its lateral flag to avoid making this
logic unhappy.  Fixed.

            regards, tom lane