Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t1X9a-00Gijx-ML for pgsql-bugs@arkaria.postgresql.org; Thu, 17 Oct 2024 20:31:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1t1X8Z-009dw7-7h for pgsql-bugs@arkaria.postgresql.org; Thu, 17 Oct 2024 20:30:23 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t1X8Y-009dtT-Ux for pgsql-bugs@lists.postgresql.org; Thu, 17 Oct 2024 20:30:23 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t1X8W-001b4E-Cr for pgsql-bugs@lists.postgresql.org; Thu, 17 Oct 2024 20:30:22 +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 49HKUH9X711201; Thu, 17 Oct 2024 16:30:17 -0400 From: Tom Lane To: Amit Langote cc: Tender Wang , Michael Paquier , exclusion@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault In-reply-to: References: <18657-1b90ccce2b16bdb8@postgresql.org> <71060.1729088799@sss.pgh.pa.us> <508107.1729126612@sss.pgh.pa.us> <569213.1729138329@sss.pgh.pa.us> Comments: In-reply-to Amit Langote message dated "Thu, 17 Oct 2024 17:15:49 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <711199.1729197017.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Thu, 17 Oct 2024 16:30:17 -0400 Message-ID: <711200.1729197017@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Amit Langote writes: > On Thu, Oct 17, 2024 at 1:12 PM Tom Lane wrote: >> In the short term, I suspect the only workable fix is to undo the >> optimization of having ExecInitExprRec not recurse into both raw_expr >> and formatted_expr. > This or actually I'm tempted to simply revert the whole thing > (b6e1157e7d3) as an ill-considered refactoring, because I am not able > to convince myself that calling ExecAggPlainTransByVal() twice, via > both raw_expr and formatted_expr, is always safe. Not following the concern here? As far as nodeAgg is concerned, they'd be two independent aggregates. In any case, whatever we do in master, you can't "simply revert" b6e1157e7 in released branches. It changed the way JsonValueExpr is represented in stored rules, and you don't get to undo that midstream. (The commit should have included a catversion bump, in fact.) I do think that reverting the ExecInitExprRec and eval_const_expressions_mutator changes would be good, but we can't undo the parser changes, at least not in v16/v17. regards, tom lane