Horton

Re: Regression with large XML data input

David G. Johnston <david.g.johnston@gmail.com>

View thread View on postgr.es
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Treat <rob@xzilla.net>, Jim Jones <jim.jones@uni-muenster.de>, Postgres hackers <pgsql-hackers@lists.postgresql.org>, Erik Wienhold <ewie@ewie.name>
Date: 2025-07-28T02:58:59Z
Lists: pgsql-hackers 
On Sunday, July 27, 2025, Michael Paquier <michael@paquier.xyz> wrote:
>
> I am not going to argue against the commits that have reached
> REL_18_STABLE to add compatibility for libxml2 2.13.X, we can leave
> this stuff as-is and enforce stronger restrictions across all versions
> of libxml2, letting users deal with application changes across a major
> version change of PG.  So, while it is not perfect and I'm aware of
> that my argument is not perfect, it would at least give packagers and
> users the option to use the previous compatibility layer if they want,
> leaving the stable branches of PG somewhat intact.  What I think is
> bad for users is the fact that Postgres closes entirely this window,
> on a stable branch, even if this was accidental based on the previous
> coding style.  I understand that from the point of view of a
> maintainer this is rather bad, but from the customer point of view the
> current situation is also bad to deal with in the scope of a minor
> upgrade, because applications suddenly break.
>

Is breaking with tradition and implementing the solution that locks down
the system but also gives DBAs the ability the make an informed runtime
decision to bypass said restriction on the table?

David J.

Commits

  1. Remove unnecessary complication around xmlParseBalancedChunkMemory.

  2. Avoid regression in the size of XML input that we will accept.

  3. Use xmlParseInNodeContext not xmlParseBalancedChunkMemory.

  4. Revert "Add support for parsing of large XML data (>= 10MB)"