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 1rTDcQ-001BZz-P6 for pgsql-bugs@arkaria.postgresql.org; Fri, 26 Jan 2024 04:15:07 +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 1rTDcP-008iTZ-Ad for pgsql-bugs@arkaria.postgresql.org; Fri, 26 Jan 2024 04:15:05 +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 1rTDcP-008iTR-2P for pgsql-bugs@lists.postgresql.org; Fri, 26 Jan 2024 04:15:05 +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 1rTDcI-003l5w-Ii for pgsql-bugs@lists.postgresql.org; Fri, 26 Jan 2024 04:15:04 +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 40Q4Et53696009; Thu, 25 Jan 2024 23:14:55 -0500 From: Tom Lane To: Michael Paquier cc: Dmitry Koval , pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18274: Error 'invalid XML content' In-reply-to: References: <5588db01-45be-48ff-b158-85f789bc502c@postgrespro.ru> <1314313.1705259848@sss.pgh.pa.us> <0eea123f-388a-41ea-9df3-d4606cf9ed8d@postgrespro.ru> <35ef78f9-8958-4225-ae7e-aead71b0feed@postgrespro.ru> <24e7412a-890c-46e3-b17d-addc39ff813f@postgrespro.ru> <99aae616-db97-4632-8934-4f39e7105631@postgrespro.ru> Comments: In-reply-to Michael Paquier message dated "Fri, 26 Jan 2024 10:24:07 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <696007.1706242495.1@sss.pgh.pa.us> Date: Thu, 25 Jan 2024 23:14:55 -0500 Message-ID: <696008.1706242495@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Michael Paquier writes: > On Thu, Jan 25, 2024 at 03:12:07PM +0300, Dmitry Koval wrote: >> I agree that reverting a patch is a good idea if there are concerns about >> server resources (XML is used by few users and there are even fewer users >> who need to parse elements larger than 10Mb). >> For such users it is better to create custom PostgreSQL build. > And done with f2743a7d70e7. Related to this: I just read some interesting things in libxml2 2.12's release notes: Most of the known issues leading to quadratic behavior in the XML parser were fixed. Internal hash tables were rewritten to reduce memory consumption. A new API function xmlCtxtSetMaxAmplification was added to allow parsing of files that would otherwise trigger the billion laughs protection. Could it be that if we see this new function is available and use it, we could allow more than we have done historically? I don't have a whole lot of faith here, but perhaps this is worth investigation. (BTW, 2.12 has created some annoying API breaks, which seems to be why caiman is failing. We have some work to do there in any case.) regards, tom lane