From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
---|---|
To: | Jacob Burroughs <jburroughs(at)instructure(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: libpq compression (part 3) |
Date: | 2024-05-17 21:10:36 |
Message-ID: | CAOYmi+nLh2kj5=VCYQWJCe5feBPKNYhZ0Q1MaOoCTyoTA1sfLQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 17, 2024 at 1:53 PM Jacob Burroughs
<jburroughs(at)instructure(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2024-05-17 21:38:34 | Re: Fix log_line_prefix to display the transaction id (%x) for statements not in a transaction block |
Previous Message | Pavel Borisov | 2024-05-17 21:08:03 | Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index. |