_after_ changing the
> protocol is not historically a winning strategy, I think. Better to do
> it as a vertical stack.
Thinking about it more, I agree that we probably should work out the
protocol level mechanism for resetting compression
context/enabling/disabling/reconfiguring compression a
using streaming compression, as the protocol
never hands over a standalone blob of compressed data: all compressed
data is always part of a stream, but even with streaming decompression
you still need some kind of limits or you will just chew up memory.)
--
Jacob Burroughs | Staff Software Engineer
E: jburrou...@instructure.com
en rows of the same
> query is a security concern.
> c. compression_restart=manual: Don't restart the stream automatically,
> but only when the client user calls a specific function. Recommended
> only if the user can make trade-offs, or if no encryption is used
> anyway.
I reasonably like this idea, though I think maybe we should also
(instead of query?) add per-transaction on the backend side. I'm
curious what other people think of this.
--
Jacob Burroughs | Staff Software Engineer
E: jburrou...@instructure.com
compressed data already has the mechanism built in (as it does) to
signal when a decompressor should restart its streaming. The actual
signaling protocol mechanism/necessary libpq API can happen in
followon work.
--
Jacob Burroughs | Staff Software Engineer
E: jburrou...@instructure.com
data as soon as the startup packet is
processed. However, as an implementation detail that clients should
not rely on but that we can rely on in thinking about the
implications, the only message types that are compressed (except in
the 0005 CI patch for test running only) are PqMsg_CopyData,
PqMsg_DataRow, and PqMsg_Query, all of which aren't sent before
authentication.
--
Jacob Burroughs | Staff Software Engineer
E: jburrou...@instructure.com
faults for
server-side compression. My overall thought though is that having an
excessive number of knobs increases the surface area for testing and
bugs while also increasing potential user confusion and that allowing
configuration on *both* sides doesn't seem sufficiently useful to be
worth adding that complexity.
--
Jacob Burroughs | Staff Software Engineer
E: jburrou...@instructure.com
the implementation details turn out to be) would also
trigger a compressor restart, and when restarted it would pick an
algorithm/configuration based on the new value of the parameter rather
than the one used at connection establishment.
--
Jacob Burroughs | Staff Software Engineer
E: jburrou...@instructure.com
messages that continue using the
already-established stream, the byte is simply set to 0. (This is
also how the "each side sends a list" form of negotiation is able to
work without additional round trips, as the `CompressedData` framing
itself communicates which compression algorithm has been selected.)
[1]
https://www.postgresql.org/message-id/CACzsqT5-7xfbz%2BSi35TBYHzerNX3XJVzAUH9AewQ%2BPp13fYBoQ%40mail.gmail.com
--
Jacob Burroughs | Staff Software Engineer
E: jburrou...@instructure.com
rver pairs may be built with support for different
compression libraries, but I think it is reasonable to say that the
side that actually has to do the computationally expensive part owns
the configuration of that part too. Maybe I'm missing a good reason
that we want to allow clients to choos
egotiable" and one for "how
should I configure my compressors" and then we reduce the dimensions
we are trying to shove into one GUC and each one ends up with a very
clear purpose:
connection_compression=(yes|no|alg1,alg2:server_to_client=alg1,alg2:client_to_server=alg3)
connection_compression_opts=gzip:level=2
--
Jacob Burroughs | Staff Software Engineer
E: jburrou...@instructure.com
ds up unused
because the two more specific ones are being used instead, but that
isn't necessarily terrible. On the server side we *could* go with
just the server_to_client and client_to_server ones, but I think we
want it to be easy to use this feature in the simple case with a
single libpq parameter.
--
Jacob Burroughs | Staff Software Engineer
E: jburrou...@instructure.com
; somebody else has got to figure out how to fix it.
If the above proposal seems better to you I'll both rework the patch
and then also try to rewrite the relevant bits of documentation to
separate out "what knobs are there" and "how do I specify the flags to
turn the kn
press=true`
algorithms and the client's `decompress=true` algorithms sent in the
`_pq_.libpq_compression` startup option. If you have a better
suggestion I am very open to it though.
--
Jacob Burroughs | Staff Software Engineer
E: jburrou...@instructure.com
> I wonder if we could use "upstream" and "downstream" to be clearer? Or
> some other terminology?
What about `send` and `receive`?
What if we created a new guc flag `GUC_PROTOCOL_EXTENSION` (or a
better name), used that for any of the GUCs options that should *only*
be set via a `ParameterSet` protocol message, and then prevent
changing those through SET/RESET/RESET ALL (but I don't see a reason
to prevent reading them through
> How about instead of talking about protocol-only GUCs (which are
> indeed currently a theoretical concept), we start considering this
> patch as a way to modify parameters for protocol extensions. Protocol
> extension parameters (starting with _pq_.) can currently only be
> configured using the S
> I'm having difficulty understanding the details of this handshaking
> algorithm from this description. It seems good that the handshake
> proceeds in each direction somewhat separately from the other, but I
> don't quite understand how the whole thing fits together. If the
> client tells the serv
> I believe this patch series is ready for detailed review/testing, with one
> caveat: as can be seen here https://cirrus-ci.com/build/6732518292979712 ,
> the build is passing on all platforms and all tests except for the primary
> SSL test on Windows.
One correction: I apparently missed a ker
18 matches
Mail list logo
