Subject: Re: libpq compression
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Robert Haas <robertmhaas@gmail.com>,
 Daniil Zakhlystov <usernamedt@yandex-team.ru>,
 Konstantin Knizhnik <k.knizhnik@postgrespro.ru>,
 Denis Smirnov <sd@arenadata.io>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: <aad16e41-b3f9-e89d-fa57-fb4c694bec25@postgrespro.ru>
 <612f227d-cb27-9238-5922-1500f8b2eb96@postgrespro.ru>
 <160623927937.7563.15974279758478581796.pgcf@coridan.postgresql.org>
 <CA+TgmoY5AMq8auemc0g3geCpVDeRnawW1A-jUeqT-5cE-_2MiA@mail.gmail.com>
 <6811D196-E2FB-40CC-B1C9-F19427FBF675@yandex-team.ru>
 <CA+TgmoZMTLydjP3iWBir20OrSXTugxS2CXC1WP1nWM5=Zqz0Nw@mail.gmail.com>
 <A1D0D9A4-1FC4-4311-83C7-EEA90749EE07@yandex-team.ru>
 <CA+TgmoZrM9T_W9YR-vLYZXj-vC_+F-DER65A87+pDXRwUFjJXg@mail.gmail.com>
 <D5354E7A-3B9F-4D32-B3AB-F65058D36500@yandex-team.ru>
 <CCAB1F57-A71D-4DEC-9A9C-F325B44BAC29@arenadata.io>
 <93027ee4-fefa-a8ca-2cc7-245c912bf824@postgrespro.ru>
 <62527092-16BD-479F-B503-FA527AF3B0C2@yandex-team.ru>
 <CA+TgmoZbVH4R5JA9_pyTSdnFTq-w2B1JvomeD+r0oo0xp1DPtQ@mail.gmail.com>
 <d889e3a2-d3f4-3f8e-aa81-c142e32ddf57@enterprisedb.com>
 <AA76CFB9-2641-4630-9E33-87BE7B89E13B@yandex-team.ru>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
Message-ID: <579f308e-c46c-2e79-3f90-9846450a3d71@enterprisedb.com>
Date: Tue, 22 Dec 2020 19:53:17 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <AA76CFB9-2641-4630-9E33-87BE7B89E13B@yandex-team.ru>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk


On 12/22/20 7:31 PM, Andrey Borodin wrote:
> 
> 
>> 22 дек. 2020 г., в 23:15, Tomas Vondra <tomas.vondra@enterprisedb.com> написал(а):
>>
>>
>>
>> On 12/22/20 6:56 PM, Robert Haas wrote:
>>> On Tue, Dec 22, 2020 at 6:24 AM Daniil Zakhlystov
>>> <usernamedt@yandex-team.ru> wrote:
>>>> When using bidirectional compression, Postgres resource usage correlates with the selected compression level. For example, here is the Postgresql application memory usage:
>>>>
>>>> No compression - 1.2 GiB
>>>>
>>>> ZSTD
>>>> zstd:1 - 1.4 GiB
>>>> zstd:7 - 4.0 GiB
>>>> zstd:13 - 17.7 GiB
>>>> zstd:19 - 56.3 GiB
>>>> zstd:20 - 109.8 GiB - did not succeed
>>>> zstd:21, zstd:22  > 140 GiB
>>>> Postgres process crashes (out of memory)
>>> Good grief. So, suppose we add compression and support zstd. Then, can
>>> unprivileged user capable of connecting to the database can negotiate
>>> for zstd level 1 and then choose to actually send data compressed at
>>> zstd level 22, crashing the server if it doesn't have a crapton of
>>> memory? Honestly, I wouldn't blame somebody for filing a CVE if we
>>> allowed that sort of thing to happen. I'm not sure what the solution
>>> is, but we can't leave a way for a malicious client to consume 140GB
>>> of memory on the server *per connection*. I assumed decompression
>>> memory was going to measured in kB or MB, not GB. Honestly, even at
>>> say L7, if you've got max_connections=100 and a user who wants to make
>>> trouble, you have a really big problem.
>>> Perhaps I'm being too pessimistic here, but man that's a lot of memory.
>>
>> Maybe I'm just confused, but my assumption was this means there's a memory leak somewhere - that we're not resetting/freeing some piece of memory, or so. Why would zstd need so much memory? It seems like a pretty serious disadvantage, so how could it become so popular?
> 
> AFAIK it's 700 clients. Does not seem like super high price for big traffic\latency reduction.
> 

I don't see aby benchmark results in this thread, allowing me to make 
that conclusion, and I find it hard to believe that 200MB/client is a 
sensible trade-off.

It assumes you have that much memory, and it may allow easy DoS attack 
(although maybe it's not worse than e.g. generating a lot of I/O or 
running expensive function). Maybe allowing limiting the compression 
level / decompression buffer size in postgresql.conf would be enough. Or 
maybe allow disabling such compression algorithms altogether.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company