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
In-reply-to: <18877-c3c3ad75845833bb@postgresql.org>
References: <18877-c3c3ad75845833bb@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Fri, 04 Apr 2025 18:48:21 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2387813.1743825262.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 04 Apr 2025 23:54:22 -0400
Message-ID: <2387814.1743825262@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2387814.1743825262%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> In the debug build of PostgreSQL 17.4, compiled with `configure
> --enable-debug --prefix=3D$(pwd) --exec-prefix=3D$(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 ( ( TABL=
E
> v00 ) ) VALUES ( FALSE ) ), any_table_name GROUP BY CUBE ( CASE WHEN TRU=
E
> THEN FALSE END );
> ```

Minimized a bit, that's

regression=3D# 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

diff --git a/src/backend/parser/parse_expr.c b/src/backend/parser/parse_ex=
pr.c
index 9caf1e481a2..bc602f00ae3 100644
--- a/src/backend/parser/parse_expr.c
+++ b/src/backend/parser/parse_expr.c
@@ -3772,7 +3772,7 @@ transformJsonArrayQueryConstructor(ParseState *pstat=
e,
 	/* Transform query only for counting target list entries. */
 	qpstate =3D make_parsestate(pstate);
 =

-	query =3D transformStmt(qpstate, ctor->query);
+	query =3D transformStmt(qpstate, copyObject(ctor->query));
 =

 	if (count_nonjunk_tlist_entries(query->targetList) !=3D 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