On Fri, May 17, 2024 at 1:53 PM Jacob Burroughs <jburrou...@instructure.com> wrote: > New proposal, predicated on the assumption that if you enable > compression you are ok with the client picking whatever level they > want. At least with the currently enabled algorithms I don't think > any of them are so insane that they would knock over a server or > anything, and in general postgres servers are usually connected to by > clients that the server admin has some channel to talk to (after all > they somehow had to get access to log in to the server in the first > place) if they are doing something wasteful, given that a client can > do a lot worse things than enable aggressive compression by writing > bad queries.
We're talking about a transport-level option, though -- I thought the proposal enabled compression before authentication completed? Or has that changed? (I'm suspicious of arguments that begin "well you can already do bad things", anyway... It seems like there's a meaningful difference between consuming resources running a parsed query and consuming resources trying to figure out what the parsed query is. I don't know if the solution is locking in a compression level, or something else; maybe they're both reasonably mitigated in the same way. I haven't really looked into zip bombs much.) --Jacob
