On Fri, Jun 12, 2026 at 07:21:28PM -0400, Tom Lane wrote:
> Hah, this idea does mostly work.  Finding that no system I had at
> hand had a libxml2 old enough to exhibit the problem, I installed
> libxml2 2.9.3 from source.  (That's the first version containing
> the problematic CVE fix, and it does behave as xml_2.out expects.)
> I found that four of the inconsistent messages could be fixed this
> way.  The other three problem cases have input like '<wrong' or
> all-spaces, and evidently we need the error to be recognized before
> reaching end-of-input.

Done that as well here, where I had to use a few switches on my Fedora
44 box to make something that I can use.  For reference after checking
out at v2.9.3:
autoreconf -i
./configure --prefix=/path/to/libxml/2.9.3/ \
  --without-threads --without-thread-alloc
make install

> Now, it seems to me that we are not especially interested in whether
> libxml2 produces one error message or another one for given input;
> what we need to test is only that Postgres reports the error
> properly.  So I don't have a problem with tweaking those bad inputs
> a bit more aggressively to make them be something that different
> libxml2 versions will report identically.  The result of my
> experiments is attached: it results in expected/xml.out that matches
> the output of both 2.9.3 and recent versions.  So if we do this
> we could drop xml_2.out.

Nice.  Confirmed that this is working here.

> This patch is WIP because I've not updated xml_1.out to match.
> But that's trivial, and dropping xml_2.out is equally boring,
> so I left those parts out of this demo patch.

I would also like to drop xml_1.out with the previous trick \if, but
at the end if you feel that there is still value in keeping some
coverage for the multiple NO_XML_SUPPORT() paths, that's fine by me.
Removing half of the regression output update pain is still better
than removing none of it.
--
Michael

Attachment: signature.asc
Description: PGP signature

Reply via email to