Thread
Commits
-
Avoid creating a RESULT RTE that's marked LATERAL.
- d23ac62afa64 15.0 landed
- 9807b9aedc6e 13.4 landed
- 1d98fdaed89c 14.0 landed
-
BUG #17097: FailedAssertion at initsplan.c
The Post Office <noreply@postgresql.org> — 2021-07-09T09:53:11Z
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] -
Re: BUG #17097: FailedAssertion at initsplan.c
John Naylor <john.naylor@enterprisedb.com> — 2021-07-09T13:41:45Z
> 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 -
Re: BUG #17097: FailedAssertion at initsplan.c
John Naylor <john.naylor@enterprisedb.com> — 2021-07-09T15:57:30Z
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
-
Re: BUG #17097: FailedAssertion at initsplan.c
Tom Lane <tgl@sss.pgh.pa.us> — 2021-07-09T16:42:41Z
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
-
Re: BUG #17097: FailedAssertion at initsplan.c
John Naylor <john.naylor@enterprisedb.com> — 2021-07-09T16:53:37Z
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
-
Re: BUG #17097: FailedAssertion at initsplan.c
Tom Lane <tgl@sss.pgh.pa.us> — 2021-07-09T17:39:58Z
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