Re: BUG #18422: Assert in expandTupleDesc() fails on row mismatch with additional SRF

PG Bug reporting form <noreply(at)postgresql(dot)org> 于2024年4月5日周五 18:35写道：

> The following bug has been logged on the website:
>
> Bug reference: 18422
> Logged by: Alexander Lakhin
> Email address: exclusion(at)gmail(dot)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(at)entry=0x55b93569420d "count <=
> tupdesc->natts",
> fileName=fileName(at)entry=0x55b9356941e6 "parse_relation.c",
> lineNumber=lineNumber(at)entry=3054) at assert.c:66
> #6 0x000055b9351841b5 in expandTupleDesc (tupdesc=0x55b9378c7660,
> eref=0x55b9378c7358, count=2, offset=offset(at)entry=0,
> rtindex=rtindex(at)entry=2, sublevels_up=sublevels_up(at)entry=0, location=-1,
> include_dropped=true, colnames=0x0,
> colvars=0x7fffaccae3e0) at parse_relation.c:3054
> #7 0x000055b93518713a in expandRTE (rte=rte(at)entry=0x55b9377fc360,
> rtindex=rtindex(at)entry=2, sublevels_up=sublevels_up(at)entry=0,
> location=location(at)entry=-1, include_dropped=include_dropped(at)entry=true,
> colnames=colnames(at)entry=0x0,
> colvars=0x7fffaccae3e0) at parse_relation.c:2758
> #8 0x000055b9353649b6 in build_physical_tlist
> (root=root(at)entry=0x55b9378c8108, rel=rel(at)entry=0x55b9378c8cf0) at
> plancat.c:1792
> #9 0x000055b935330653 in create_scan_plan (root=root(at)entry
> =0x55b9378c8108,
> best_path=best_path(at)entry=0x55b9378c9340, flags=<optimized out>,
> flags(at)entry=0) at createplan.c:637
> #10 0x000055b93532dd65 in create_plan_recurse
> (root=root(at)entry=0x55b9378c8108, best_path=0x55b9378c9340,
> flags=flags(at)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(at)entry
> =0x55b9378c8108,
> best_path=best_path(at)entry=0x55b9377fc470) at createplan.c:1076
> #13 0x000055b93532dd75 in create_plan_recurse
> (root=root(at)entry=0x55b9378c8108, best_path=0x55b9377fc470,
> flags=flags(at)entry=1) at createplan.c:416
> #14 0x000055b93532e575 in create_plan (root=root(at)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(at)entry=0x55b9377fbf78,
> query_string=query_string(at)entry=0x55b9377fa888 "SELECT * FROM
> generate_series(1, 1),\n COALESCE(row(1)) AS (a int, b int);",
> cursorOptions=cursorOptions(at)entry=2048,
> boundParams=boundParams(at)entry=0x0) at planner.c:281
> #17 0x000055b93542c257 in pg_plan_query
> (querytree=querytree(at)entry=0x55b9377fbf78,
> query_string=query_string(at)entry=0x55b9377fa888 "SELECT * FROM
> generate_series(1, 1),\n COALESCE(row(1)) AS (a int, b int);",
> cursorOptions=cursorOptions(at)entry=2048,
> boundParams=boundParams(at)entry=0x0) at postgres.c:904
> #18 0x000055b93542c30d in pg_plan_queries (querytrees=0x55b9378c80b8,
> query_string=query_string(at)entry=0x55b9377fa888 "SELECT * FROM
> generate_series(1, 1),\n COALESCE(row(1)) AS (a int, b int);",
> cursorOptions=cursorOptions(at)entry=2048,
> boundParams=boundParams(at)entry=0x0) at postgres.c:996
> #19 0x000055b93542c7f0 in exec_simple_query
> (query_string=query_string(at)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().)
>

Thanks for reporting this issue.
Before d57534740, it returned TYPEFUNC_RECORD in get_expr_result_type().
So it would not call expandTupleDesc(), but it would ereport in
tupledesc_match().

I copy the ereport code in tupledesc_match() into expandRTE() if
funcolcount is larger
than natts. The attached patch looks like a workaround fix.

--
Tender Wang
OpenPie: https://en.openpie.com/