On Sun, Jul 27, 2025 at 10:16:47PM -0400, Tom Lane wrote: > Michael Paquier <mich...@paquier.xyz> writes: >> 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. > > Hmm, okay, I misread Jim's results then. But there still remains > the big question: what reason is there to believe that it's safe > to return to the old behavior? If newer libxml2 versions report > XML_ERR_RESOURCE_LIMIT on the same input, doesn't it seem likely > that there's a live hazard in the old code?
Yes, I guess that it's not entirely safe to use libxml2 2.9.X if we rely on the old code, but it also sucks for customers that relied on the old bevahior to not have a way out in stable branches, and there are still plenty of environments that rely on 2.9.X. That's the reason why I am suggesting an hybrid approach on stable branches where the regression shows up, where it would be possible to store large XML data values for *some* cases, keeping some compatibility: - if building Postgres with 2.13.X, use the new code, as on HEAD, forcing the restrictions. - if building Postgres with 2.12.X or older, then use the old code, as in what Postgres did before f68d6aabb. If one wants to enforce a stricter behavior, then it is enough to upgrade the version of libxml2 on a stable branch of PG. If one wants to preserve compatibility, then keep the older version of libxml2 but be aware that, while things are compatible in terms of input handling, libxml2 was unsafe and it was so for years. Hence, based on the number of environments still using 2.9.X, that seems worth the hack on stable branches. 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. -- Michael
signature.asc
Description: PGP signature
