From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Treat <rob@xzilla.net>
cc: Michael Paquier <michael@paquier.xyz>,
        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
In-reply-to: 
 <CABV9wwOY3pH+pA0R1hSq5g_DXqeDaGWRuoBEE4QwWLfTiw+nKw@mail.gmail.com>
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>
Comments: In-reply-to Robert Treat <rob@xzilla.net>
	message dated "Fri, 25 Jul 2025 14:02:47 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <1944117.1753467686.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 25 Jul 2025 14:21:26 -0400
Message-ID: <1944118.1753467686@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1944118.1753467686%40sss.pgh.pa.us>
Precedence: bulk

Robert Treat <rob@xzilla.net> writes:
> On Thu, Jul 24, 2025 at 8:08=E2=80=AFPM Michael Paquier <michael@paquier=
.xyz> wrote:
>> If it were discussing things from the perspective where this new code
>> was added after a major version bump of Postgres, I would not argue
>> much about that: breakages happen every year and users adapt their
>> applications to it.  Here, however, we are talking about a change in a
>> stable branch, across a minor version, which should be a bit more
>> flawless from a user perspective?

> While I am pretty sympathetic to the idea that we hang our hats on
> "Postgres doesn't break things in minor version updates", and this
> seems to betray that, one scenario where we would break things is if
> it were the only reasonable option wrt a bug / security fix, which
> this seems potentially close to.

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.

I'd be more excited about trying to avoid the failure if I were not
afraid that "avoid the failure" really means "re-expose a security
hazard".  Why should we believe that if libxml2 throws a
resource-limit error (for identical inputs) in one code path and not
another, that's anything but a missed error check in the second path?
(Maybe this is the same thing Robert is saying, not quite sure.)

> There are a lot of public data sets that provide xml dumps as a
> generic format for "non-commercial databases", and those can often be
> quite large. I suspect we don't see those use cases a lot because
> historically users have been forced to resort to perl/python/etc
> scripts to convert the data prior to ingesting. Which is to say, I
> think these use cases are more common than we think, and if there were
> ever a stable implementation that supported these large use cases,
> we'll start to see more of it.

Yeah, it's a real shame that we don't have more-reliable
infrastructure for XML.  I'm not volunteering to fix it though...

			regards, tom lane