Re: Defer selection of asynchronous subplans until the executor initialization stage

On Fri, Apr 8, 2022 at 5:43 AM Justin Pryzby <pryzby(at)telsasoft(dot)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(at)entry=0x7f4219ed93b0,
> path=path(at)entry=0x7f4219e89538) at createplan.c:1132
> #2 0x000055b439691924 in create_append_plan (root=root(at)entry=0x55b43affb2b0,
> best_path=best_path(at)entry=0x7f4219ed0cb8, flags=flags(at)entry=0) at
> createplan.c:1329
> #3 0x000055b43968fa21 in create_plan_recurse (root=root(at)entry=0x55b43affb2b0,
> best_path=best_path(at)entry=0x7f4219ed0cb8, flags=flags(at)entry=0) at
> createplan.c:421
> #4 0x000055b43968f974 in create_projection_plan (root=root(at)entry=0x55b43affb2b0,
> best_path=best_path(at)entry=0x7f4219ed0f60, flags=flags(at)entry=1) at
> createplan.c:2039
> #5 0x000055b43968fa6f in create_plan_recurse (root=root(at)entry=0x55b43affb2b0,
> best_path=0x7f4219ed0f60, flags=flags(at)entry=1) at createplan.c:433
> #6 0x000055b439690221 in create_plan (root=root(at)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(at)entry=0x55b43af05e28,
> query_string=query_string(at)entry=0x55b43af04c40 "SELECT 1 FROM
> information_schema.constraint_column_usage WHERE 1 > pg_trigger_depth();",
> cursorOptions=cursorOptions(at)entry=2048, boundParams=boundParams(at)entry=0x0)
> at planner.c:277
> #9 0x000055b439790c78 in pg_plan_query (querytree=querytree(at)entry=0x55b43af05e28,
> query_string=query_string(at)entry=0x55b43af04c40 "SELECT 1 FROM
> information_schema.constraint_column_usage WHERE 1 > pg_trigger_depth();",
> cursorOptions=cursorOptions(at)entry=2048, boundParams=boundParams(at)entry=0x0)
> at postgres.c:883
> #10 0x000055b439790d54 in pg_plan_queries (querytrees=0x55b43afdd528,
> query_string=query_string(at)entry=0x55b43af04c40 "SELECT 1 FROM
> information_schema.constraint_column_usage WHERE 1 > pg_trigger_depth();",
> cursorOptions=cursorOptions(at)entry=2048, boundParams=boundParams(at)entry=0x0)
> at postgres.c:975
> #11 0x000055b439791239 in exec_simple_query
> (query_string=query_string(at)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(at)entry=0x55b43af2ffe0) at
> postmaster.c:4489
> #14 0x000055b4396e9c03 in BackendStartup (port=port(at)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(at)entry=0x55b439a61238 "plan->scanstatus ==
> SUBQUERY_SCAN_UNKNOWN", errorType=errorType(at)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.