Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rSyad-00H9CH-PQ for pgsql-bugs@arkaria.postgresql.org; Thu, 25 Jan 2024 12:12:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rSyac-00GIJT-A1 for pgsql-bugs@arkaria.postgresql.org; Thu, 25 Jan 2024 12:12:14 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rSyab-00GIJL-T6 for pgsql-bugs@lists.postgresql.org; Thu, 25 Jan 2024 12:12:14 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rSyaY-003e7M-Op for pgsql-bugs@lists.postgresql.org; Thu, 25 Jan 2024 12:12:13 +0000 Received: from [172.30.11.66] (unknown [172.30.11.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: d.koval@postgrespro.ru) by mail.postgrespro.ru (Postfix/587) with ESMTPSA id 7CF66E21059; Thu, 25 Jan 2024 15:12:08 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1706184728; bh=n6XgUHrDewzIGqMHGgRcQcrWwf98v8r0ZyK+zcx0y34=; h=Message-ID:Date:User-Agent:Subject:To:Cc:References:From: In-Reply-To:From; b=ScoAEamLkEibGLQX8ViQVhZXk5LRYMf/qGtCgCTrT4GI3CZ3Yx5D2Zu0wz8Q7v2dA pKNpqDrGiR0xtxYepsFU0m6T0kPpGRv0BTEy94Po3sh0vzx6l8VnqBgDQzRjfL1/e9 c+HcBNIvkSFwlZpLNhMuSDDqTNqsYa0d4H2bb0CPKvDjhGm1Eibn6lAjK+9hTCCdYL kr9yC9A2SMpof5m2qUvXmxIqADwWYBrVsdr1+b+LF3jS27bX7rLPEYB5AH4uyI/kSr xOzlQY0BWGAl30QbG+qs7Nn4xGs954+TS4Rm/odyPQfenAzXEd2+UiQd3CAH2A+Btb dLcjXJSYJs0Rw== Message-ID: <99aae616-db97-4632-8934-4f39e7105631@postgrespro.ru> Date: Thu, 25 Jan 2024 15:12:07 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: BUG #18274: Error 'invalid XML content' Content-Language: en-US To: Michael Paquier Cc: pgsql-bugs@lists.postgresql.org References: <18274-98d16bc03520665f@postgresql.org> <1616257.1704651529@sss.pgh.pa.us> <5588db01-45be-48ff-b158-85f789bc502c@postgrespro.ru> <1314313.1705259848@sss.pgh.pa.us> <0eea123f-388a-41ea-9df3-d4606cf9ed8d@postgrespro.ru> <35ef78f9-8958-4225-ae7e-aead71b0feed@postgrespro.ru> <24e7412a-890c-46e3-b17d-addc39ff813f@postgrespro.ru> From: Dmitry Koval In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.100.3 at postfix X-Virus-Status: Clean List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > he security team has discussed 2197d06224a1 after a report from > coverity regarding the effects that issues like [1] would create in > the backend, and concluded that this patch should be reverted because > this could cause the backend to waste plently of CPU and/or memory > even if the application applied checks on the size of the data given > in input, and libxml2 does not offer guarantees that input limits are > respected under XML_PARSE_HUGE. Thanks for info! I agree that reverting a patch is a good idea if there are concerns about server resources (XML is used by few users and there are even fewer users who need to parse elements larger than 10Mb). For such users it is better to create custom PostgreSQL build. -- With best regards, Dmitry Koval Postgres Professional: http://postgrespro.com