Re: Defer selection of asynchronous subplans until the executor initialization stage
Zhihong Yu <zyu@yugabyte.com>
From: Zhihong Yu <zyu@yugabyte.com>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Etsuro Fujita <etsuro.fujita@gmail.com>,
Alexander Pyhalov <a.pyhalov@postgrespro.ru>, "Andrey V. Lepikhov" <a.lepikhov@postgrespro.ru>,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2022-04-08T16:28:43Z
Lists: pgsql-hackers
On Fri, Apr 8, 2022 at 5:43 AM Justin Pryzby <pryzby@telsasoft.com> wrote: > On Wed, Apr 06, 2022 at 03:58:29PM +0900, Etsuro Fujita wrote: > > I have committed the patch after modifying it as such. (I think we > > can improve these later, if necessary.) > > This patch seems to be causing the planner to crash. > Here's a query reduced from sqlsmith. > > | explain SELECT 1 FROM information_schema.constraint_column_usage WHERE 1 > <= pg_trigger_depth(); > > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x000055b4396a2edf in trivial_subqueryscan (plan=0x7f4219ed93b0) at > ../../../../src/include/nodes/pg_list.h:151 > 151 return l ? l->length : 0; > (gdb) bt > #0 0x000055b4396a2edf in trivial_subqueryscan (plan=0x7f4219ed93b0) at > ../../../../src/include/nodes/pg_list.h:151 > #1 0x000055b43968af89 in mark_async_capable_plan (plan=plan@entry=0x7f4219ed93b0, > path=path@entry=0x7f4219e89538) at createplan.c:1132 > #2 0x000055b439691924 in create_append_plan (root=root@entry=0x55b43affb2b0, > best_path=best_path@entry=0x7f4219ed0cb8, flags=flags@entry=0) at > createplan.c:1329 > #3 0x000055b43968fa21 in create_plan_recurse (root=root@entry=0x55b43affb2b0, > best_path=best_path@entry=0x7f4219ed0cb8, flags=flags@entry=0) at > createplan.c:421 > #4 0x000055b43968f974 in create_projection_plan (root=root@entry=0x55b43affb2b0, > best_path=best_path@entry=0x7f4219ed0f60, flags=flags@entry=1) at > createplan.c:2039 > #5 0x000055b43968fa6f in create_plan_recurse (root=root@entry=0x55b43affb2b0, > best_path=0x7f4219ed0f60, flags=flags@entry=1) at createplan.c:433 > #6 0x000055b439690221 in create_plan (root=root@entry=0x55b43affb2b0, > best_path=<optimized out>) at createplan.c:348 > #7 0x000055b4396a1451 in standard_planner (parse=0x55b43af05e28, > query_string=<optimized out>, cursorOptions=2048, boundParams=0x0) at > planner.c:413 > #8 0x000055b4396a19c1 in planner (parse=parse@entry=0x55b43af05e28, > query_string=query_string@entry=0x55b43af04c40 "SELECT 1 FROM > information_schema.constraint_column_usage WHERE 1 > pg_trigger_depth();", > cursorOptions=cursorOptions@entry=2048, boundParams=boundParams@entry=0x0) > at planner.c:277 > #9 0x000055b439790c78 in pg_plan_query (querytree=querytree@entry=0x55b43af05e28, > query_string=query_string@entry=0x55b43af04c40 "SELECT 1 FROM > information_schema.constraint_column_usage WHERE 1 > pg_trigger_depth();", > cursorOptions=cursorOptions@entry=2048, boundParams=boundParams@entry=0x0) > at postgres.c:883 > #10 0x000055b439790d54 in pg_plan_queries (querytrees=0x55b43afdd528, > query_string=query_string@entry=0x55b43af04c40 "SELECT 1 FROM > information_schema.constraint_column_usage WHERE 1 > pg_trigger_depth();", > cursorOptions=cursorOptions@entry=2048, boundParams=boundParams@entry=0x0) > at postgres.c:975 > #11 0x000055b439791239 in exec_simple_query > (query_string=query_string@entry=0x55b43af04c40 "SELECT 1 FROM > information_schema.constraint_column_usage WHERE 1 > pg_trigger_depth();") > at postgres.c:1169 > #12 0x000055b439793183 in PostgresMain (dbname=<optimized out>, > username=<optimized out>) at postgres.c:4542 > #13 0x000055b4396e6af7 in BackendRun (port=port@entry=0x55b43af2ffe0) at > postmaster.c:4489 > #14 0x000055b4396e9c03 in BackendStartup (port=port@entry=0x55b43af2ffe0) > at postmaster.c:4217 > #15 0x000055b4396e9e4a in ServerLoop () at postmaster.c:1791 > #16 0x000055b4396eb401 in PostmasterMain (argc=7, argv=<optimized out>) at > postmaster.c:1463 > #17 0x000055b43962b4df in main (argc=7, argv=0x55b43aeff0c0) at main.c:202 > > Actually, the original query failed like this: > #2 0x000055b4398e9f90 in ExceptionalCondition > (conditionName=conditionName@entry=0x55b439a61238 "plan->scanstatus == > SUBQUERY_SCAN_UNKNOWN", errorType=errorType@entry=0x55b43994b00b > "FailedAssertion", > #3 0x000055b4396a2ecf in trivial_subqueryscan (plan=0x55b43b59cac8) at > setrefs.c:1367 > Hi, I logged the value of plan->scanstatus before the assertion : 2022-04-08 16:20:59.601 UTC [26325] LOG: scan status 0 2022-04-08 16:20:59.601 UTC [26325] STATEMENT: explain SELECT 1 FROM information_schema.constraint_column_usage WHERE 1 <= pg_trigger_depth(); 2022-04-08 16:20:59.796 UTC [26296] LOG: server process (PID 26325) was terminated by signal 11: Segmentation fault It seems its value was SUBQUERY_SCAN_UNKNOWN. Still trying to find out the cause for the crash.
Commits
-
Improve comments for trivial_subqueryscan().
- 4a8a5dd7f59c 15.0 landed
-
Disable asynchronous execution if using gating Result nodes.
- ebb790241523 14.3 landed
- 5c854e7a2c8a 15.0 landed
-
Allow asynchronous execution in more cases.
- c2bb02bc2e85 15.0 landed
-
Doc: Further update documentation for asynchronous execution.
- eab81953682d 14.0 landed
-
Fix rescanning of async-aware Append nodes.
- f3baaf28a6da 14.0 landed
-
Doc: Update documentation for asynchronous execution.
- 15fcd33e0694 14.0 landed
-
Fix EXPLAIN ANALYZE for async-capable nodes.
- a363bc6da96b 14.0 landed
-
Minor code cleanup in asynchronous execution support.
- bb684c82f733 14.0 landed
-
Adjust input value to WaitEventSetWait() in ExecAppendAsyncEventWait().
- a8af856d3257 14.0 landed
-
Add support for asynchronous execution.
- 27e1f14563cf 14.0 landed