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 1ugSaj-003YBq-8L for pgsql-hackers@arkaria.postgresql.org; Mon, 28 Jul 2025 18:28:53 +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 1ugSai-009rSH-Dn for pgsql-hackers@arkaria.postgresql.org; Mon, 28 Jul 2025 18:28:52 +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 1ugSai-009rS6-4E for pgsql-hackers@lists.postgresql.org; Mon, 28 Jul 2025 18:28:52 +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 1ugSae-001FKx-0c for pgsql-hackers@lists.postgresql.org; Mon, 28 Jul 2025 18:28:49 +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 56SIShQs483422; Mon, 28 Jul 2025 14:28:43 -0400 From: Tom Lane To: Erik Wienhold cc: Jim Jones , Michael Paquier , Robert Treat , Postgres hackers Subject: Re: Regression with large XML data input In-reply-to: <457dd309-158f-43cd-81d4-df7284f30d4f@ewie.name> References: <1691195.1753383449@sss.pgh.pa.us> <1721385.1753385039@sss.pgh.pa.us> <7a9a9804-01d8-4489-a831-1a222bae6705@uni-muenster.de> <1944118.1753467686@sss.pgh.pa.us> <314265.1753669007@sss.pgh.pa.us> <457dd309-158f-43cd-81d4-df7284f30d4f@ewie.name> Comments: In-reply-to Erik Wienhold message dated "Mon, 28 Jul 2025 12:49:02 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <483420.1753727323.1@sss.pgh.pa.us> Date: Mon, 28 Jul 2025 14:28:43 -0400 Message-ID: <483421.1753727323@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Erik Wienhold writes: > I'm leaning towards Michael's proposal of adding a libxml2 version check > in the stable branches before REL_18_STABLE and parsing the content with > xmlParseBalancedChunkMemory on versions up to 2.12.x. I spent some time investigating this. It appears that even when using our old code with xmlParseBalancedChunkMemory (I tested against our commit 6082b3d5d^), libxml2 versions 2.12.x and 2.13.x will throw a resource-exhaustion error; but earlier and later releases do not. Drilling down with "git bisect", the first libxml2 commit that throws an error is commit 834b8123efc4a4c369671cad2f1b0eb744ae67e9 Author: Nick Wellnhofer Date: Tue Aug 8 15:21:28 2023 +0200 parser: Stream data when reading from memory Don't create a copy of the whole input buffer. Read the data chunk by chunk to save memory. and then the one that restores it to not throwing an error is commit 7148b778209aaaf684c156c5e2e40d6e477f13f7 Author: Nick Wellnhofer Date: Sun Jul 7 16:11:08 2024 +0200 parser: Optimize memory buffer I/O Reenable zero-copy IO for zero-terminated static memory buffers. Don't stream zero-terminated dynamic memory buffers on top of creating a copy. So apparently the "resource exhaustion" complaint is not about anything deeper than not wanting to make a copy of a many-megabyte input string, and the fact that it appeared and disappeared is an artifact of libxml2 implementation choices that we have no control over (and, IMO, no responsibility for working around). Based on this, I'm okay with reverting to using xmlParseBalancedChunkMemory: while that won't help users of 2.12.x or 2.13.x, it will help users of earlier and later libxml2. But I think we should just do that across the board, not insert libxml2 version tests nor do it differently in different PG versions. I've not looked at the details of the proposed patches, but will do so now that the direction to go in is apparent. regards, tom lane