Re: libpq compression

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: libpq compression
Дата
Msg-id 626075.1608663785@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: libpq compression  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Ответы Re: libpq compression  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Re: libpq compression  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Список pgsql-hackers
Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> 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.

The link Ken pointed at suggests that restricting the window size to
8MB is a common compromise.  It's not clear to me what that does to
the achievable compression ratio.  Even 8MB could be an annoying cost
if it's being paid per-process, on both the server and client sides.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: libpq compression
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] [PATCH] Generic type subscripting