Re: libpq compression (part 3)
От | Jelte Fennema-Nio |
---|---|
Тема | Re: libpq compression (part 3) |
Дата | |
Msg-id | CAGECzQQ4iQ=bhtC4E_rVs6XYAgQMzcjvUr-rGRdKPkGT0VKqgA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: libpq compression (part 3) (Jacob Champion <jacob.champion@enterprisedb.com>) |
Ответы |
Re: libpq compression (part 3)
Re: libpq compression (part 3) |
Список | pgsql-hackers |
On Fri, 17 May 2024 at 23:10, Jacob Champion <jacob.champion@enterprisedb.com> wrote: > We're talking about a transport-level option, though -- I thought the > proposal enabled compression before authentication completed? Or has > that changed? I think it would make sense to only compress messages after authentication has completed. The gain of compressing authentication related packets seems pretty limited. > (I'm suspicious of arguments that begin "well you can already do bad > things" Once logged in it's really easy to max out a core of the backend you're connected as. There's many trivial queries you can use to do that. An example would be: SELECT sum(i) from generate_series(1, 1000000000) i; So I don't think it makes sense to worry about an attacker using a high compression level as a means to DoS the server. Sending a few of the above queries seems much easier.
В списке pgsql-hackers по дате отправления: