From: Tom Lane <tgl@sss.pgh.pa.us>
To: luy70@psu.edu
Cc: pgsql-bugs@lists.postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
Subject: Re: BUG #18877: PostgreSQL triggers assertion failure
Date: Fri, 04 Apr 2025 23:54:22 -0400
Message-ID: <2387814.1743825262@sss.pgh.pa.us> (raw)
In-Reply-To: <18877-c3c3ad75845833bb@postgresql.org>
References: <18877-c3c3ad75845833bb@postgresql.org>
PG Bug reporting form <noreply@postgresql.org> writes:
> In the debug build of PostgreSQL 17.4, compiled with `configure
> --enable-debug --prefix=$(pwd) --exec-prefix=$(pwd) --enable-cassert`,
> triggered Assertion Failure when executing the following statement:
> ```sql
> SELECT ALL GROUP BY ALL ( ), CUBE ( CASE WHEN FALSE THEN TRUE END )
> INTERSECT ALL SELECT ALL FROM JSON_ARRAY ( WITH any_cte_name AS ( ( TABLE
> v00 ) ) VALUES ( FALSE ) ), any_table_name GROUP BY CUBE ( CASE WHEN TRUE
> THEN FALSE END );
> ```
Minimized a bit, that's
regression=# SELECT 1 FROM JSON_ARRAY ( WITH any_cte_name AS ( ( select 1 ) ) VALUES ( FALSE ) );
server closed the connection unexpectedly
This is another case of "don't let the parser process the same
querytree twice". I can make it go away with
inline patch 1: src/backend/parser/parse_expr.c (+1/-1 lines) download inline-1.patchdiff --git a/src/backend/parser/parse_expr.c b/src/backend/parser/parse_expr.cindex 9caf1e481a2..bc602f00ae3 100644--- a/src/backend/parser/parse_expr.c+++ b/src/backend/parser/parse_expr.c@@ -3772,7 +3772,7 @@ transformJsonArrayQueryConstructor(ParseState *pstate,
/* Transform query only for counting target list entries. */
qpstate = make_parsestate(pstate);
- query = transformStmt(qpstate, ctor->query);+ query = transformStmt(qpstate, copyObject(ctor->query));
if (count_nonjunk_tlist_entries(query->targetList) != 1)
ereport(ERROR,
However ... it's possible that this isn't the stupidest, most
brute-force code in Postgres, but I'll wager it's in the top ten.
Is it really necessary to transform the subquery twice just to
produce this error? It seems like the constructed EXPR_SUBLINK
should produce the same error all by itself. I tried nuking this
whole stanza to see whether that would happen, and then there are a
couple of regression test cases that don't produce the same results.
But I feel like it could be made to work with a bit more thought.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, luy70@psu.edu, alvherre@alvh.no-ip.org
Subject: Re: BUG #18877: PostgreSQL triggers assertion failure
In-Reply-To: <2387814.1743825262@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox