Server crashes when execute query "WITH RECURSIVE"

[saygoodbyye]

What happens?

Server crashes if execute script below
PostgreSQL build:

CFLAGS='-Og' ./configure --enable-tap-tests --with-openssl --enable-debug --enable-cassert --with-icu --with-lz4 --with-libxml

To Reproduce

test.sql:

CREATE EXTENSION pg_duckdb;
WITH RECURSIVE outermost(x) AS (
 SELECT 1
 UNION (WITH innermost1 AS (
  SELECT 2
  UNION (WITH innermost2 AS (
   SELECT 3
   UNION (WITH innermost3 AS (
    SELECT 4
    UNION (WITH innermost4 AS (
     SELECT 5
     UNION (WITH innermost5 AS (
      SELECT 6
      UNION (WITH innermost6 AS
       (SELECT 7)
       SELECT * FROM innermost6))
      SELECT * FROM innermost5))
     SELECT * FROM innermost4))
    SELECT * FROM innermost3))
   SELECT * FROM innermost2))
  SELECT * FROM outermost
  UNION SELECT * FROM innermost1)
 )
 SELECT * FROM outermost ORDER BY 1;

backtrace:

#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3  0x00007e6fd904526e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0x00007e6fd90288ff in __GI_abort () at ./stdlib/abort.c:79
#5  0x000062c065354bda in ExceptionalCondition (conditionName=conditionName@entry=0x7e6fd97e8818 "subquery->setOperations == NULL", fileName=fileName@entry=0x7e6fd97e9edd "src/vendor/pg_ruleutils_17.c", lineNumber=lineNumber@entry=6178) at assert.c:66
#6  0x00007e6fd97dc1b3 in get_setop_query (setOp=<optimized out>, query=query@entry=0x62c065a33ed0, context=context@entry=0x7ffee9c44df0, resultDesc=resultDesc@entry=0x0, colNamesVisible=colNamesVisible@entry=false)
    at src/vendor/pg_ruleutils_17.c:6178
#7  0x00007e6fd97dc2ff in get_setop_query (setOp=0x62c065a3d5c0, query=query@entry=0x62c065a33ed0, context=context@entry=0x7ffee9c44df0, resultDesc=resultDesc@entry=0x0, colNamesVisible=colNamesVisible@entry=true) at src/vendor/pg_ruleutils_17.c:6275
#8  0x00007e6fd97dd839 in get_select_query_def (query=query@entry=0x62c065a33ed0, context=context@entry=0x7ffee9c44df0, resultDesc=resultDesc@entry=0x0, colNamesVisible=colNamesVisible@entry=true) at src/vendor/pg_ruleutils_17.c:5715
#9  0x00007e6fd97da75a in get_query_def (query=0x62c065a33ed0, buf=buf@entry=0x7ffee9c45100, parentnamespace=0x62c065a3dec8, resultDesc=resultDesc@entry=0x0, colNamesVisible=colNamesVisible@entry=true, prettyFlags=0, wrapColumn=0, startIndent=0)
    at src/vendor/pg_ruleutils_17.c:5469
#10 0x00007e6fd97db660 in get_with_clause (query=query@entry=0x62c065a333d8, context=context@entry=0x7ffee9c44fd0) at src/vendor/pg_ruleutils_17.c:5608
#11 0x00007e6fd97dd7f3 in get_select_query_def (query=query@entry=0x62c065a333d8, context=context@entry=0x7ffee9c44fd0, resultDesc=resultDesc@entry=0x0, colNamesVisible=colNamesVisible@entry=true) at src/vendor/pg_ruleutils_17.c:5700
#12 0x00007e6fd97da75a in get_query_def (query=query@entry=0x62c065a333d8, buf=buf@entry=0x7ffee9c45100, parentnamespace=parentnamespace@entry=0x0, resultDesc=resultDesc@entry=0x0, colNamesVisible=colNamesVisible@entry=true,
    prettyFlags=prettyFlags@entry=0, wrapColumn=0, startIndent=0) at src/vendor/pg_ruleutils_17.c:5469
#13 0x00007e6fd97de39d in pgduckdb_pg_get_querydef_internal (query=0x62c065a333d8, pretty=<optimized out>) at src/vendor/pg_ruleutils_17.c:1581
#14 0x00007e6fd97b587b in pgduckdb_get_querydef (query=0x62c065a333d8) at src/pgduckdb_ruleutils.cpp:177
#15 0x00007e6fd97b4a19 in DuckdbPrepare (query=query@entry=0x62c06591f580) at src/pgduckdb_planner.cpp:41
#16 0x00007e6fd97b4c69 in CreatePlan (throw_error=<optimized out>, query=0x62c06591f580) at src/pgduckdb_planner.cpp:65
#17 pgduckdb::__CPPFunctionGuard__<Plan* (*)(Query*, bool), CreatePlan, Query*, bool> (func_name=0x7e6fd97e9687 "DuckdbPlanNode") at src/pgduckdb_planner.cpp:116
#18 0x00007e6fd97b4fb1 in DuckdbPlanNode (parse=parse@entry=0x62c06591f580,
    query_string=query_string@entry=0x62c0658bfef0 "WITH RECURSIVE outermost(x) AS (\n SELECT 1\n UNION (WITH innermost1 AS (\n  SELECT 2\n  UNION (WITH innermost2 AS (\n   SELECT 3\n   UNION (WITH innermost3 AS (\n    SELECT 4\n    UNION (WITH innermost4 AS ("..., cursor_options=cursor_options@entry=2048, bound_params=bound_params@entry=0x0, throw_error=throw_error@entry=false) at src/pgduckdb_planner.cpp:116
#19 0x00007e6fd97ade84 in DuckdbPlannerHook_Cpp (bound_params=0x0, cursor_options=2048,
    query_string=0x62c0658bfef0 "WITH RECURSIVE outermost(x) AS (\n SELECT 1\n UNION (WITH innermost1 AS (\n  SELECT 2\n  UNION (WITH innermost2 AS (\n   SELECT 3\n   UNION (WITH innermost3 AS (\n    SELECT 4\n    UNION (WITH innermost4 AS ("...,
    parse=0x62c06591f580) at src/pgduckdb_hooks.cpp:204
#20 pgduckdb::__CPPFunctionGuard__<PlannedStmt* (*)(Query*, char const*, int, ParamListInfoData*), DuckdbPlannerHook_Cpp, Query*, char const*, int, ParamListInfoData*> (func_name=0x7e6fd97e9349 "DuckdbPlannerHook") at src/pgduckdb_hooks.cpp:221
#21 0x000062c06512194e in planner (parse=parse@entry=0x62c06591f580,
    query_string=query_string@entry=0x62c0658bfef0 "WITH RECURSIVE outermost(x) AS (\n SELECT 1\n UNION (WITH innermost1 AS (\n  SELECT 2\n  UNION (WITH innermost2 AS (\n   SELECT 3\n   UNION (WITH innermost3 AS (\n    SELECT 4\n    UNION (WITH innermost4 AS ("..., cursorOptions=cursorOptions@entry=2048, boundParams=boundParams@entry=0x0) at planner.c:280
#22 0x000062c06520bd4b in pg_plan_query (querytree=querytree@entry=0x62c06591f580,
    query_string=query_string@entry=0x62c0658bfef0 "WITH RECURSIVE outermost(x) AS (\n SELECT 1\n UNION (WITH innermost1 AS (\n  SELECT 2\n  UNION (WITH innermost2 AS (\n   SELECT 3\n   UNION (WITH innermost3 AS (\n    SELECT 4\n    UNION (WITH innermost4 AS ("..., cursorOptions=cursorOptions@entry=2048, boundParams=boundParams@entry=0x0) at postgres.c:908
#23 0x000062c06520be01 in pg_plan_queries (querytrees=0x62c065a33208,
    query_string=query_string@entry=0x62c0658bfef0 "WITH RECURSIVE outermost(x) AS (\n SELECT 1\n UNION (WITH innermost1 AS (\n  SELECT 2\n  UNION (WITH innermost2 AS (\n   SELECT 3\n   UNION (WITH innermost3 AS (\n    SELECT 4\n    UNION (WITH innermost4 AS ("..., cursorOptions=cursorOptions@entry=2048, boundParams=boundParams@entry=0x0) at postgres.c:1000
#24 0x000062c06520c263 in exec_simple_query (
    query_string=query_string@entry=0x62c0658bfef0 "WITH RECURSIVE outermost(x) AS (\n SELECT 1\n UNION (WITH innermost1 AS (\n  SELECT 2\n  UNION (WITH innermost2 AS (\n   SELECT 3\n   UNION (WITH innermost3 AS (\n    SELECT 4\n    UNION (WITH innermost4 AS ("...) at postgres.c:1197
#25 0x000062c06520e28c in PostgresMain (dbname=<optimized out>, username=<optimized out>) at postgres.c:4767
#26 0x000062c06520788a in BackendMain (startup_data=<optimized out>, startup_data_len=<optimized out>) at backend_startup.c:105
#27 0x000062c065161faa in postmaster_child_launch (child_type=child_type@entry=B_BACKEND, startup_data=startup_data@entry=0x7ffee9c45734 "", startup_data_len=startup_data_len@entry=4, client_sock=client_sock@entry=0x7ffee9c45770)
    at launch_backend.c:277
#28 0x000062c0651666a5 in BackendStartup (client_sock=client_sock@entry=0x7ffee9c45770) at postmaster.c:3593
#29 0x000062c06516691f in ServerLoop () at postmaster.c:1674
#30 0x000062c065167f91 in PostmasterMain (argc=argc@entry=3, argv=argv@entry=0x62c06587a050) at postmaster.c:1372
#31 0x000062c0650896ee in main (argc=3, argv=0x62c06587a050) at main.c:197

OS:

Ubuntu 24.04

pg_duckdb Version (if built from source use commit hash):

d75ed5d

Postgres Version (if built from source use commit hash):

7af6d13061ee00924f555bcb77bb2499f1aa03f8

Hardware:

No response

Full Name:

Egor Chindyaskin

Affiliation:

Postgres Professional

What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.

I have tested with a source build

Did you include all relevant data sets for reproducing the issue?

Yes

Did you include all code required to reproduce the issue?

• Yes, I have

Did you include all relevant configuration (e.g., CPU architecture, Linux distribution) to reproduce the issue?

• Yes, I have

[Leo-XM-Zeng]

Interestingly, using PG's native "pg_get_querydef" also triggers this assertion.

[Leo-XM-Zeng]

https://www.postgresql.org/message-id/18710-ceab935c95da55aa%40postgresql.org

[JelteF]

postgresql.org/message-id/18710-ceab935c95da55aa%40postgresql.org

I think it makes sense if you also post a patch to that thread to fix the issue (i.e. by removing the assert).

[Leo-XM-Zeng]

postgresql.org/message-id/18710-ceab935c95da55aa%40postgresql.org

I think it makes sense if you also post a patch to that thread to fix the issue (i.e. by removing the assert).

Thanks for your reminding, I tried to submit a patch.