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 1pcYRO-0000Fj-JR for pgsql-hackers@arkaria.postgresql.org; Wed, 15 Mar 2023 21:13:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pcYRN-00017h-5S for pgsql-hackers@arkaria.postgresql.org; Wed, 15 Mar 2023 21:13:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pcYRM-00017Y-SI for pgsql-hackers@lists.postgresql.org; Wed, 15 Mar 2023 21:13:44 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pcYRK-0006iR-Cu for pgsql-hackers@lists.postgresql.org; Wed, 15 Mar 2023 21:13:44 +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 32FLDaD43622267; Wed, 15 Mar 2023 17:13:37 -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: <3057762.1678836321@sss.pgh.pa.us> References: <2f5df461-dad8-6d7d-4568-08e10608a69b@uni-muenster.de> <4c2efca5-8257-2424-6687-07c65e319e95@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> Comments: In-reply-to Tom Lane message dated "Tue, 14 Mar 2023 19:25:21 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3622265.1678914816.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Mar 2023 17:13:36 -0400 Message-ID: <3622266.1678914816@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > Huh, interesting. That is a legitimate pretty-fication of the input, > I suppose, but some people might think it goes beyond the charter of > "indentation". I'm okay with it personally; anyone want to object? Hearing no objections to that, I moved ahead with this. It occurred to me to test v23 for memory leaks, and it had bad ones: * the "newline" node used in the CONTENT case never got freed. Making another one for each line wasn't helping, either. * libxml, at least in the 2.9.7 version I have here, turns out to leak memory if you pass a non-null encoding to xmlSaveToBuffer. But AFAICS we don't really need to do that, because the last thing we want is for libxml to try to do any encoding conversion. After cleaning that up, I saw that we were indeed doing essentially duplicative xml_parse calls for the DOCUMENT check and the indentation work, so I refactored to allow just one call to serve. Pushed with those changes and some other cosmetic cleanup. Thanks for working so hard on this! (Now to keep an eye on the buildfarm, to see if other versions of libxml work like mine ...) BTW, the libxml leak problem seems to extend to other cases too. I tested with code like do $$ declare x xml; t text; begin x :=3D '73'; for i in 1..10000000 loop t :=3D xmlserialize(document x as text); end loop; raise notice 't =3D %', t; end; $$; That case is fine, but if you change the encoding spec to "latin1", it leaks like mad. That problem is not the fault of this patch, I don't think. I wonder if we need to do something to prevent libxml from seeing encoding declarations other than utf8? regards, tom lane