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 <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1uf0Or-000rxf-2I
	for pgsql-hackers@arkaria.postgresql.org; Thu, 24 Jul 2025 18:10:37 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.94.2)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1uf0Op-009jsj-U0
	for pgsql-hackers@arkaria.postgresql.org; Thu, 24 Jul 2025 18:10:36 +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 <tgl@sss.pgh.pa.us>)
	id 1uf0Op-009jsb-Ks
	for pgsql-hackers@lists.postgresql.org; Thu, 24 Jul 2025 18:10:35 +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 <tgl@sss.pgh.pa.us>)
	id 1uf0Oo-000amC-0e
	for pgsql-hackers@lists.postgresql.org;
	Thu, 24 Jul 2025 18:10:35 +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 56OIATiV1685957;
	Thu, 24 Jul 2025 14:10:30 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>,
        Erik Wienhold <ewie@ewie.name>
Subject: Re: Regression with large XML data input
In-reply-to: <1569825.1753327718@sss.pgh.pa.us>
References: <aIGknLuc8b8ega2X@paquier.xyz> <1569825.1753327718@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Wed, 23 Jul 2025 23:28:38 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1685955.1753380629.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 24 Jul 2025 14:10:29 -0400
Message-ID: <1685956.1753380629@sss.pgh.pa.us>
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: 
 <https://www.postgresql.org/message-id/1685956.1753380629%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> A customer has reported a regression with the parsing of rather large
>> XML data, introduced by the set of backpatches done with f68d6aabb7e2
>> & friends.

> Bleah.

The supplied test case hides important details in the error message.
If you get rid of the exception block so that the error is reported
in full, what you see is

regression=3D# CREATE TEMP TABLE xmldata (id BIGINT PRIMARY KEY, message X=
ML );
CREATE TABLE
regression=3D# DO $$ DECLARE size_40mb TEXT :=3D repeat('X', 40000000);
regression$# BEGIN
regression$#    INSERT INTO xmldata (id, message) VALUES
regression$#      ( 1, (('<Root><Item><Name>Test40MB</Name><Content>' || s=
ize_40mb || '</Content></Item></Root>')::xml) );
regression$# END $$;
ERROR:  invalid XML content
DETAIL:  line 1: internal error: Huge input lookup
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=
XXXXXX
                                                                          =
     ^
CONTEXT:  SQL statement "INSERT INTO xmldata (id, message) VALUES
     ( 1, (('<Root><Item><Name>Test40MB</Name><Content>' || size_40mb || '=
</Content></Item></Root>')::xml) )"
PL/pgSQL function inline_code_block line 3 at SQL statement
regression=3D# =


That is, what we are hitting is libxml2's internal protections
against processing "too large" input.  I am not really sure
why the other coding failed to hit this same thing, but I wonder
if we shouldn't leave well enough alone.  See commits 2197d0622
and f2743a7d7, where we tried to enable such cases and then
decided it was too risky.  I'm afraid now that our prior coding
might have allowed billion-laugh-like cases to be reachable.

			regards, tom lane