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 1uHtAY-00Bnir-62 for pgsql-hackers@arkaria.postgresql.org; Wed, 21 May 2025 23:48:18 +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 1uHtAV-00CeEk-KS for pgsql-hackers@arkaria.postgresql.org; Wed, 21 May 2025 23:48:15 +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 1uHtAV-00CeEb-An for pgsql-hackers@lists.postgresql.org; Wed, 21 May 2025 23:48:15 +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.96) (envelope-from ) id 1uHtAS-000DeV-0v for pgsql-hackers@lists.postgresql.org; Wed, 21 May 2025 23:48:14 +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 54LNm5UD1418828; Wed, 21 May 2025 19:48:05 -0400 From: Tom Lane To: Jim Jones cc: Peter Smith , Peter Eisentraut , Nikolay Samokhvalov , PostgreSQL Hackers , Andrey Borodin Subject: Re: [PATCH] Add pretty-printed XML output option In-reply-to: <552cf981-643e-417b-88f4-1476c1320c36@uni-muenster.de> References: <2f5df461-dad8-6d7d-4568-08e10608a69b@uni-muenster.de> <2eac4d78-2b20-e8ec-54cc-22a88653a1cc@uni-muenster.de> <6cb296fe-4b49-3691-633e-2e2366997b04@uni-muenster.de> <3baf8f25-3bd7-7db5-0b31-e4c92b6269ba@enterprisedb.com> <1cbe1087-6acb-2b0a-dc9b-0a2d5b99e466@uni-muenster.de> <532259.1678393296@sss.pgh.pa.us> <906cfd1d-63a0-3cf5-7291-2dadb2e! 149ff@uni-muenster.de> <803304.1678458776@sss.pgh.pa.us> <2752578.1678815625@sss.pgh.pa.us> <3057762.1678836321@sss.pgh.pa.us> <3622266.1678914816@sss.pgh.pa.us> <1c7cf9f0-14c3-0341-6894! -8ca577bf325e@uni-muenster.de> <1358967.1747858817@sss.pgh.pa.us> Comments: In-reply-to Jim Jones message dated "Thu, 22 May 2025 01:15:57 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1418826.1747871285.1@sss.pgh.pa.us> Date: Wed, 21 May 2025 19:48:05 -0400 Message-ID: <1418827.1747871285@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Jim Jones writes: > On 21.05.25 22:20, Tom Lane wrote: >> It turns out that xmlDocSetRootElement() doesn't >> merely install the given root node: it unlinks the document's old >> root node and returns it to you. If you don't free it, it's leaked >> (for the session, since this is a malloc not palloc). > The xmlsoft examples are a bit misleading though [1] Yeah. I also did some searching on http://codesearch.debian.net and was hard put to it to find anything that pays attention to xmlDocSetRootElement's result at all. I wonder how many of those represent leaks. > It seems that xml_parse has the same issue[3] I did look at that one too. I think it's fine, because we're dealing with a newly-created document which can't have a root node yet. (Reinforcing this, Valgrind sees no leaks after applying my patch.) I considered adding an assertion that that call returns NULL, but concluded that it wasn't worth the notational hassle. I'm not strongly set on that conclusion, though, if you think differently. regards, tom lane