Обсуждение: 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]
> run the following sql command through client and the PostgreSQL database
> process will crash:
Thanks for the report! Unfortunately, the stack trace was not informative, because there are no debug symbols. Here's a minimal reproducer, which also traps an assertion on PG13. I'll bisect and see how far back it goes.
SELECT v1 FROM LATERAL COALESCE (27) v1
WHERE v1 IN (
SELECT 42 as v1
);
TRAP: FailedAssertion("false", File: "prepjointree.c", Line: 2164, PID: 1322)
0 postgres 0x000000010e78ecd4 ExceptionalCondition + 132
1 postgres 0x000000010e589d85 replace_vars_in_jointree + 613
2 postgres 0x000000010e589c94 replace_vars_in_jointree + 372
3 postgres 0x000000010e589c24 replace_vars_in_jointree + 260
4 postgres 0x000000010e589c94 replace_vars_in_jointree + 372
5 postgres 0x000000010e5899e7 perform_pullup_replace_vars + 199
6 postgres 0x000000010e587382 pull_up_subqueries_recurse + 1954
7 postgres 0x000000010e586ea4 pull_up_subqueries_recurse + 708
8 postgres 0x000000010e586e09 pull_up_subqueries_recurse + 553
9 postgres 0x000000010e586b75 pull_up_subqueries + 37
10 postgres 0x000000010e5761ed subquery_planner + 573
11 postgres 0x000000010e5759c7 standard_planner + 359
12 postgres 0x000000010e65a39f pg_plan_query + 111
13 postgres 0x000000010e65a462 pg_plan_queries + 82
14 postgres 0x000000010e65e9d2 exec_simple_query + 1154
--
John Naylor
EDB: http://www.enterprisedb.com
I wrote:
> Thanks for the report! Unfortunately, the stack trace was not informative, because there are no debug symbols. Here's a minimal reproducer, which also traps an assertion on PG13. I'll bisect and see how far back it goes.
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.
--
John Naylor
EDB: http://www.enterprisedb.com
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.
--
John Naylor
EDB: http://www.enterprisedb.com
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
On Fri, Jul 9, 2021 at 12:42 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> 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
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
--
John Naylor
EDB: http://www.enterprisedb.com
case RTE_CTE:
case RTE_NAMEDTUPLESTORE:
case RTE_RESULT:
/* these shouldn't be marked LATERAL */
Assert(false);
break;
where the plan has RTE_RESULT
--
John Naylor
EDB: http://www.enterprisedb.com
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