From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dmitry Koval <d(dot)koval(at)postgrespro(dot)ru>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18274: Error 'invalid XML content' |
Date: | 2024-01-15 04:18:54 |
Message-ID: | ZaSyLnPwVpzHxDCU@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sun, Jan 14, 2024 at 10:16:33PM -0500, Tom Lane wrote:
> Blowing out a backend's memory or CPU consumption is not something
> we try hard to prevent, so I'm not terribly worried on that score.
> The one thing I'm concerned about is that raising these limits could
> make bugs (like integer overflow problems) reachable that were not
> otherwise, and that such bugs might rise to the level of security
> problems. They've had such issues before (CVE-2022-40303) and it'd be
> foolish to be sure that none remain. Still, that's clearly their bug
> not our bug.
Interesting. We could always keep our coding more defensive, not sure
entirely how. I am not sure that this is enough to not just use the
upper limit, though. Being able to manipulate larger XML elements
sounds like a fair argument from the user perspective these days,
especially with memory being cheaper and larger.
1fb2e0dfc631 has added the huge option back in 2009 in libxml2, so
it's been around for some time.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Zu-Ming Jiang | 2024-01-15 07:48:27 | Re: BUG #18292: Unexpected error: "relation "hobbies_r" does not exist" caused by user-defined functions |
Previous Message | Tom Lane | 2024-01-15 03:16:33 | Re: BUG #18274: Error 'invalid XML content' |