Feedback-ID: i0fe9450f:Fastmail
Date: Mon, 28 Jul 2025 11:09:33 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Treat <rob@xzilla.net>, Jim Jones <jim.jones@uni-muenster.de>,
	Postgres hackers <pgsql-hackers@lists.postgresql.org>,
	Erik Wienhold <ewie@ewie.name>
Subject: Re: Regression with large XML data input
Message-ID: <aIbb3TOq3XP923e5@paquier.xyz>
References: <aIGknLuc8b8ega2X@paquier.xyz>
 <1569825.1753327718@sss.pgh.pa.us>
 <1685956.1753380629@sss.pgh.pa.us>
 <1691195.1753383449@sss.pgh.pa.us>
 <1721385.1753385039@sss.pgh.pa.us>
 <7a9a9804-01d8-4489-a831-1a222bae6705@uni-muenster.de>
 <aILK3nMlw6pp-XhA@paquier.xyz>
 <CABV9wwOY3pH+pA0R1hSq5g_DXqeDaGWRuoBEE4QwWLfTiw+nKw@mail.gmail.com>
 <1944118.1753467686@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="8VWGkgmoucW0497F"
Content-Disposition: inline
In-Reply-To: <1944118.1753467686@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/aIbb3TOq3XP923e5%40paquier.xyz>
Precedence: bulk


--8VWGkgmoucW0497F
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Jul 25, 2025 at 02:21:26PM -0400, Tom Lane wrote:
> I'll be the first to say that I'm not too pleased with it either.
> However, from Jim Jones' result upthread, a "minor update" of libxml2
> could also have caused this problem: 2.9.7 and 2.9.14 behave
> differently.  So we don't have sole control --- or sole responsibility
> --- here.

This sentence is incorrect after I have double-checked the behaviors I
am seeing based on local builds of libxml2 2.9.7 and 2.9.14.  For
example with the top of REL_15_STABLE, with and without
72c65d6658d4, I am getting (removing the exception in the example does
not matter if it's a success):
- libxml2 2.9.7  + top of REL_15_STABLE => test failure
- libxml2 2.9.14 + top of REL_15_STABLE => test failure
- libxml2 2.9.7  + top of REL_15_STABLE + revert of 72c65d6658d4
=> test success
- libxml2 2.9.14 + top of REL_15_STABLE + revert of 72c65d6658d4
=> test success

So if one uses a version of libxml2 2.9.X, he/she would be able to see
the large data case work with Postgres at 72c65d6658d4^1, and a
failure with 72c65d6658d4 and onwards.  Taking Postgres in isolation
with any version of libxml2 in the 2.9.X series prevents the case to
work.  This does not depend on 2.9.X, only on the fact that we link
Postgres to a newer major version of libxml2.

Please note that this is also the behavior I see in a Debian GID
environment and I guess any existing Debian release: we rely on
libxml2 2.9.X, so a minor upgrade of Postgres is the factor able to
trigger the behavior change.  It seems to me that there's an argument
for compatibility with the 2.9.X series, which still seems quite
present in the wild, and that we could decide one solution over the
other in xml_parse() based on LIBXML_VERSION.  What I am seeing is
that at fixed major version of libxml2, then Postgres holds the
responsibility here.
--
Michael

--8VWGkgmoucW0497F
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmiG290ACgkQnvQgOdby
QH0b0xAAgvLpM6nLdzgcHmCuirBYyMVOOoXNBEIaCnoQCzYt+SzbViauc0XhCOUK
k45VUnXK92UWz4mmYVkEKS/tL808nehccyxGuQ8rKBWVvyKdHEERkKMbEI92B07G
Cm5DYkwv69Nc6+HsdLBvYDJpY8SlHCVNO4j7aBJ69HE1r4IhsTIHGCMd4a5F6EGN
wZJ/xa0ZnZS2nNez1E1RKYpRILLaiC46iX3X9ilKIbPfUMa/rjOdjpqwpq1UJIDf
HDnwapLAzF3EHpUF1LdrnjFL5Pzpnc/ckwLhyczGIv+/zWiWmRN6kPh0g3sSY712
SnnmVLug0vQHW6v7gAeeVB7IsvFs/710S48F6fAi+BHH/ZBI3Zb9ZDo13bS8jDcL
C3G8NmQlC8k8O3JOlCgGxI3DiokBIb/NNT3L1th2M1N6HjBJ8Ad2F2eDj7FWjU7w
Guid8dXZdMPRz9S+OMS0NRBeiKlkskJzFvyUb+BQzO+s2IVdc/nkuFS7J2qI/g05
JMzYllD+keqaeQBxUEuHYGknPVy3IUq7aZlgIggXFOWyTh+ZjOa+xqfT+DBIknzN
csS6GYVL8SCri6kfcGM6Gdw7MLt1q7SXBz2B6zuZl6BJ+/tROanOYMwMlwWJnSTo
koryjek2YcA81rSiS0B94zMCHT3Gm5WgOGv7MBfonhmEgP2zBZE=
=Llvt
-----END PGP SIGNATURE-----

--8VWGkgmoucW0497F--