| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Dmitry Koval <d(dot)koval(at)postgrespro(dot)ru> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #18274: Error 'invalid XML content' |
| Date: | 2024-01-14 23:34:05 |
| Message-ID: | ZaRvbaQ8V9uGxXGD@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Sun, Jan 14, 2024 at 11:58:07PM +0300, Dmitry Koval wrote:
>> Is there some downside to XML_PARSE_HUGE?
>
> I didn't see any problems during simple testing of patch with the
> XML_PARSE_HUGE.
> Extended testing will be performed soon.
> Then (I hope) we will send a trial version of PostgreSQL with a patch to
> customers who use XML.
If one looks at the libxml2 like this mirror at [1], it is possible to
see that the flag is only used to lift internal hard limits, for stuff
like XML_MAX_TEXT_LENGTH and XML_MAX_NAME_LENGTH for size control, or
max node depths.
Knowing that we have full control of the memory contexts for the XML
nodes, just enforcing the huge flag does not seem like there's any
downside for us. (Right?)
[1]: https://github.com/GNOME/libxml2
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrei Lepikhov | 2024-01-15 00:20:37 | Re: BUG #18260: Unexpected error: "negative bitmapset member not allowed" triggered by multiple JOIN |
| Previous Message | Dmitry Koval | 2024-01-14 20:58:07 | Re: BUG #18274: Error 'invalid XML content' |