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 1u5BoN-00DcEN-2r for pgsql-hackers@arkaria.postgresql.org; Wed, 16 Apr 2025 23:04:55 +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 1u5BoL-007iHu-Au for pgsql-hackers@arkaria.postgresql.org; Wed, 16 Apr 2025 23:04:54 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u5BoK-007iH6-WD for pgsql-hackers@lists.postgresql.org; Wed, 16 Apr 2025 23:04:53 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1u5BoJ-000RdL-1r for pgsql-hackers@lists.postgresql.org; Wed, 16 Apr 2025 23:04:52 +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 53GN4ogp2084688; Wed, 16 Apr 2025 19:04:51 -0400 From: Tom Lane To: Daniel Gustafsson cc: pgsql-hackers@lists.postgresql.org Subject: Re: jsonapi: scary new warnings with LTO enabled In-reply-to: References: <2074634.1744839761@sss.pgh.pa.us> <0A3CF5C4-9947-42E3-89A9-34FCF7BA95BA@yesql.se> <2078511.1744841564@sss.pgh.pa.us> Comments: In-reply-to Daniel Gustafsson message dated "Thu, 17 Apr 2025 00:18:23 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2084686.1744844690.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Apr 2025 19:04:50 -0400 Message-ID: <2084687.1744844690@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Daniel Gustafsson writes: > On 17 Apr 2025, at 00:12, Tom Lane wrote: >> The only alternative I can see that might stop the warning is if we >> can find a way to make it clearer to the optimizer that the FREE() >> isn't reached. But I'm not sure about a trustworthy way to make that >> happen. > Yeah, that seems messy enough that someone down the line will go "why on= earth" > and we'll have to revisit this discussion. It can probably be made to w= ork but > I doubt it will be worth it compared to allocating on the heap. Looking through all of the callers of freeJsonLexContext, quite a lot of them use local JsonLexContext structs, and probably some of them are more performance-critical than these. So that raises the question of why are we seeing warnings for only these call sites? Maybe there is a more elegant way to suppress them. Still, I think that observation refutes my initial thought that we should rip out support for local JsonLexContext structs altogether. I'm inclined now to just do the minimal thing of changing these callers to use an allocated struct, and call it a day. (BTW, there seem to be only 2 places to change not 3; two of the warnings are pointing at the same variable.) regards, tom lane