From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Treat <rob@xzilla.net>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Jim Jones <jim.jones@uni-muenster.de>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Cc: Erik Wienhold <ewie@ewie.name>
Subject: Re: Regression with large XML data input
Date: Fri, 25 Jul 2025 14:21:26 -0400
Message-ID: <1944118.1753467686@sss.pgh.pa.us> (raw)
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>
Robert Treat <rob@xzilla.net> writes:
> On Thu, Jul 24, 2025 at 8:08 PM 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, rob@xzilla.net, michael@paquier.xyz, jim.jones@uni-muenster.de, pgsql-hackers@lists.postgresql.org, ewie@ewie.name
Subject: Re: Regression with large XML data input
In-Reply-To: <1944118.1753467686@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox