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
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
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