BUG #18422: Assert in expandTupleDesc() fails on row mismatch with additional SRF - Mailing list pgsql-bugs
From | PG Bug reporting form |
---|---|
Subject | BUG #18422: Assert in expandTupleDesc() fails on row mismatch with additional SRF |
Date | |
Msg-id | 18422-89ca86c8eac5246d@postgresql.org Whole thread Raw |
Responses |
Re: BUG #18422: Assert in expandTupleDesc() fails on row mismatch with additional SRF
|
List | pgsql-bugs |
The following bug has been logged on the website: Bug reference: 18422 Logged by: Alexander Lakhin Email address: exclusion@gmail.com PostgreSQL version: 16.2 Operating system: Ubuntu 22.04 Description: The following query: SELECT * FROM generate_series(1, 1), COALESCE(row(1)) AS (a int, b int); triggers an assertion failure: TRAP: failed Assert("count <= tupdesc->natts"), File: "parse_relation.c", Line: 3054, PID: 151361 with the following stack trace: ... #5 0x000055b935579366 in ExceptionalCondition (conditionName=conditionName@entry=0x55b93569420d "count <= tupdesc->natts", fileName=fileName@entry=0x55b9356941e6 "parse_relation.c", lineNumber=lineNumber@entry=3054) at assert.c:66 #6 0x000055b9351841b5 in expandTupleDesc (tupdesc=0x55b9378c7660, eref=0x55b9378c7358, count=2, offset=offset@entry=0, rtindex=rtindex@entry=2, sublevels_up=sublevels_up@entry=0, location=-1, include_dropped=true, colnames=0x0, colvars=0x7fffaccae3e0) at parse_relation.c:3054 #7 0x000055b93518713a in expandRTE (rte=rte@entry=0x55b9377fc360, rtindex=rtindex@entry=2, sublevels_up=sublevels_up@entry=0, location=location@entry=-1, include_dropped=include_dropped@entry=true, colnames=colnames@entry=0x0, colvars=0x7fffaccae3e0) at parse_relation.c:2758 #8 0x000055b9353649b6 in build_physical_tlist (root=root@entry=0x55b9378c8108, rel=rel@entry=0x55b9378c8cf0) at plancat.c:1792 #9 0x000055b935330653 in create_scan_plan (root=root@entry=0x55b9378c8108, best_path=best_path@entry=0x55b9378c9340, flags=<optimized out>, flags@entry=0) at createplan.c:637 #10 0x000055b93532dd65 in create_plan_recurse (root=root@entry=0x55b9378c8108, best_path=0x55b9378c9340, flags=flags@entry=0) at createplan.c:411 #11 0x000055b93532f585 in create_nestloop_plan (root=0x55b9378c8108, best_path=0x55b9377fc470) at createplan.c:4342 #12 0x000055b93532f6be in create_join_plan (root=root@entry=0x55b9378c8108, best_path=best_path@entry=0x55b9377fc470) at createplan.c:1076 #13 0x000055b93532dd75 in create_plan_recurse (root=root@entry=0x55b9378c8108, best_path=0x55b9377fc470, flags=flags@entry=1) at createplan.c:416 #14 0x000055b93532e575 in create_plan (root=root@entry=0x55b9378c8108, best_path=<optimized out>) at createplan.c:347 #15 0x000055b93533ff5b in standard_planner (parse=0x55b9377fbf78, query_string=<optimized out>, cursorOptions=2048, boundParams=<optimized out>) at planner.c:420 #16 0x000055b9353404f8 in planner (parse=parse@entry=0x55b9377fbf78, query_string=query_string@entry=0x55b9377fa888 "SELECT * FROM generate_series(1, 1),\n COALESCE(row(1)) AS (a int, b int);", cursorOptions=cursorOptions@entry=2048, boundParams=boundParams@entry=0x0) at planner.c:281 #17 0x000055b93542c257 in pg_plan_query (querytree=querytree@entry=0x55b9377fbf78, query_string=query_string@entry=0x55b9377fa888 "SELECT * FROM generate_series(1, 1),\n COALESCE(row(1)) AS (a int, b int);", cursorOptions=cursorOptions@entry=2048, boundParams=boundParams@entry=0x0) at postgres.c:904 #18 0x000055b93542c30d in pg_plan_queries (querytrees=0x55b9378c80b8, query_string=query_string@entry=0x55b9377fa888 "SELECT * FROM generate_series(1, 1),\n COALESCE(row(1)) AS (a int, b int);", cursorOptions=cursorOptions@entry=2048, boundParams=boundParams@entry=0x0) at postgres.c:996 #19 0x000055b93542c7f0 in exec_simple_query (query_string=query_string@entry=0x55b9377fa888 "SELECT * FROM generate_series(1, 1),\n COALESCE(row(1)) AS (a int, b int);") at postgres.c:1193 (gdb) frame 6 (gdb) p tupdesc->natts $1 = 1 Reproduced on REL_12_STABLE .. master. `git bisect` blames d57534740 (8a15b4178 on REL_12_STABLE). (Thanks to Amit Langote for correcting my initial report where this issue was hastily attributed to JSON_TABLE().)
pgsql-bugs by date: