Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pbk47-0002Bi-Iz for pgsql-bugs@arkaria.postgresql.org; Mon, 13 Mar 2023 15:26:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pbk46-00021g-1k for pgsql-bugs@arkaria.postgresql.org; Mon, 13 Mar 2023 15:26:22 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pbk45-00021W-Pd for pgsql-bugs@lists.postgresql.org; Mon, 13 Mar 2023 15:26:21 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pbk43-0005rR-Ed for pgsql-bugs@lists.postgresql.org; Mon, 13 Mar 2023 15:26:20 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 32DFQEVX1772190; Mon, 13 Mar 2023 11:26:16 -0400 From: Tom Lane To: xinwen@stu.scu.edu.cn cc: pgsql-bugs@lists.postgresql.org, Andres Freund Subject: Re: BUG #17835: Two assertions failed in nodeAgg.c and execExprInterp.c with the same SQL In-reply-to: <17835-4f29f3098b2d0ba4@postgresql.org> References: <17835-4f29f3098b2d0ba4@postgresql.org> Comments: In-reply-to PG Bug reporting form message dated "Mon, 13 Mar 2023 02:58:25 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1772188.1678721174.1@sss.pgh.pa.us> Date: Mon, 13 Mar 2023 11:26:14 -0400 Message-ID: <1772189.1678721174@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk PG Bug reporting form writes: > When executing the following query with CTE: > WITH table1 ( column25 ) AS ( SELECT 1 ) SELECT FROM ( SELECT column25 > column12 FROM table1 ) AS alias0 GROUP BY column12 HAVING AVG ( ( SELECT 1 > FROM table1 JOIN ( SELECT AVG ( column25 ORDER BY CASE 1 WHEN column12 THEN > ( SELECT AVG ( column12 ) FROM table1 ) END ) column14 FROM table1 ) AS > alias3 ON alias3 . column14 = 1 ) ) = 1 ; > I get a failed assertion with the following stacktrace: Simplifying a bit, we get WITH table1 ( col1 ) AS ( SELECT 1 ) SELECT AVG(( SELECT AVG ( a1.col1 ORDER BY ( SELECT AVG ( a2.col2 ) FROM table1 ) ) FROM table1 a1 )) FROM table1 AS a2(col2); PG v10 says ERROR: aggregate function calls cannot be nested which seems correct: per spec, the innermost AVG actually should belong to the outer query level that sources a2.col2. Later versions fail to detect that the query is nonsensical and end up with nonsensical executor state instead. I bisected this to 69c3936a1499b772a749ae629fc59b2d72722332 is the first bad commit commit 69c3936a1499b772a749ae629fc59b2d72722332 Author: Andres Freund Date: Tue Jan 9 13:25:38 2018 -0800 Expression evaluation based aggregate transition invocation. So that commit broke something about the nested-aggregate detection logic. It's not completely gone: if we simplify this to WITH table1 ( col1 ) AS ( SELECT 1 ) SELECT AVG(( SELECT AVG ( ( SELECT AVG ( a2.col2 ) FROM table1 ) ) FROM table1 a1 )) FROM table1 AS a2(col2); we still get ERROR: aggregate function calls cannot be nested LINE 3: SELECT AVG ( ( SELECT AVG ( a2.col2 ) FROM table1 ) ) ^ v10 detected this in ExecInitAgg, while later versions are trying to do it in the parser, but evidently there's some gap there ... regards, tom lane