On Thu, Nov 17, 2011 at 10:11, Albe Laurenz laurenz.a...@wien.gv.at wrote:
I wrote:
Here it is. I'll add it to the November commitfest.
Here is the second version.
I realized that it is better to set the option on the SSL object
and not on the SSL context so that it is possible to change it
I wrote:
Here it is. I'll add it to the November commitfest.
Here is the second version.
I realized that it is better to set the option on the SSL object
and not on the SSL context so that it is possible to change it
per connection.
I also improved the documentation.
Yours,
Laurenz Albe
Bruce Momjian wrote:
I'd still be willing to write a patch for a client-only solution.
Agreed. There is clearly a win in turning off SSL compression for
certain workloads, and if people think the client is the right
location,
then let's do it there.
Here it is. I'll add it to the November
Tom Lane wrote:
But in any case, my objection is that there's no adequate use-case
for this GUC, because it's much more sensible to set it from the
client
side. We have too many GUCs already --- Josh B regularly goes on the
warpath looking for ones we can remove. This one should never get in
Albe Laurenz wrote:
Tom Lane wrote:
But in any case, my objection is that there's no adequate use-case
for this GUC, because it's much more sensible to set it from the
client
side. We have too many GUCs already --- Josh B regularly goes on the
warpath looking for ones we can remove.
Magnus Hagander wrote:
Is the following proposal acceptable:
- Add a GUC ssl_compression, defaulting to on.
- Add a client option sslcompression and an environment variable
PGSSLCOMPRESSION, defaulting to 1.
Seems like the reasonable thing, yes.
Compression will be disabled if either
On 11/08/2011 12:39 PM, Tom Lane wrote:
Jeroen Vermeulenj...@xs4all.nl writes:
Another reason why I believe compression is often used with encryption
is to maximize information content per byte of data: harder to guess,
harder to crack. Would that matter?
Yes, it would. There's a reason
On Thursday, November 10, 2011, Andrew Dunstan wrote:
On 11/08/2011 12:39 PM, Tom Lane wrote:
Jeroen Vermeulenj...@xs4all.nl writes:
Another reason why I believe compression is often used with encryption
is to maximize information content per byte of data: harder to guess,
harder to
Tom Lane wrote:
Is the following proposal acceptable:
- Add a GUC ssl_compression, defaulting to on.
- Add a client option sslcompression and an environment variable
PGSSLCOMPRESSION, defaulting to 1.
A GUC is entirely, completely, 100% the wrong answer. It has no way
to
deal with the
Albe Laurenz laurenz.a...@wien.gv.at writes:
Tom Lane wrote:
A GUC is entirely, completely, 100% the wrong answer. It has no way
to deal with the fact that some clients may need compression and others
not.
You can force a certain SSL cipher on the client, why not a compression
setting?
To
On Thu, Nov 10, 2011 at 11:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
But in any case, my objection is that there's no adequate use-case
for this GUC, because it's much more sensible to set it from the client
side. We have too many GUCs already --- Josh B regularly goes on the
warpath looking
On Thu, Nov 10, 2011 at 5:18 PM, Albe Laurenz laurenz.a...@wien.gv.at wrote:
I could go and try to convince Npgsql and JDBC to accept patches to
do that on the client side, but that would be more effort than I
want to invest. But then there's still closed source software like
Devart
Tom Lane wrote:
Albe Laurenz laurenz.a...@wien.gv.at writes:
Tom Lane wrote:
A GUC is entirely, completely, 100% the wrong answer. It has no way
to deal with the fact that some clients may need compression and others
not.
You can force a certain SSL cipher on the client, why not a
Bruce Momjian br...@momjian.us writes:
How is the compression connection parameter set? It seems odd for it to
be compiled into the application because the application could be run on
different networks. I don't know of any way to inject connection
options from outside the application like
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
How is the compression connection parameter set? It seems odd for it to
be compiled into the application because the application could be run on
different networks. I don't know of any way to inject connection
options from outside
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Huh? You put it in the connection string, typically. This is not
different from how you'd specify sslmode to start with.
Well, you are saying the client is more flexible, but if the client is a
binary, it isn't flexible without an
Christopher Browne wrote:
I think that JDBC and Npgsql should also support disabling
compression.
That's the *real* problem here...
You're quite right that if we allow controlling this on the libpq
side, it is surely desirable to allow controlling this via JDBC,
Npgsql, and other
On Wednesday, November 9, 2011, Albe Laurenz wrote:
Christopher Browne wrote:
I think that JDBC and Npgsql should also support disabling
compression.
That's the *real* problem here...
You're quite right that if we allow controlling this on the libpq
side, it is surely desirable to
Magnus Hagander mag...@hagander.net writes:
On Wednesday, November 9, 2011, Albe Laurenz wrote:
Is the following proposal acceptable:
- Add a GUC ssl_compression, defaulting to on.
- Add a client option sslcompression and an environment variable
PGSSLCOMPRESSION, defaulting to 1.
Seems
On Wed, Nov 09, 2011 at 05:26:14PM -0500, Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On Wednesday, November 9, 2011, Albe Laurenz wrote:
Is the following proposal acceptable:
- Add a GUC ssl_compression, defaulting to on.
- Add a client option sslcompression and an
I ran into a performance problem described in this thread:
http://archives.postgresql.org/pgsql-performance/2011-10/msg00249.php
continued here:
http://archives.postgresql.org/pgsql-performance/2011-11/msg00045.php
OpenSSL compresses data by default, and that causes a
performance penalty of 100%
On Tue, Nov 8, 2011 at 14:59, Albe Laurenz laurenz.a...@wien.gv.at wrote:
I ran into a performance problem described in this thread:
http://archives.postgresql.org/pgsql-performance/2011-10/msg00249.php
continued here:
http://archives.postgresql.org/pgsql-performance/2011-11/msg00045.php
On 11/08/2011 03:59 PM, Albe Laurenz wrote:
If there are concerns about that, maybe a GUC variable like
ssl_compression (defaulting to off) would be a solution.
I'd vote for a libpq connect option instead. Something like
sslcompress=yes|no accompanied by PGSSLCOMPRESS environment
variable.
On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenz laurenz.a...@wien.gv.at wrote:
It is possible that this could cause a performance
regression for people who SELECT lots of compressible
data over really slow network connections, but is that
a realistic scenario?
Yes, it's a realistic scenario.
Marko Kreen mark...@gmail.com writes:
On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenz laurenz.a...@wien.gv.at wrote:
It is possible that this could cause a performance
regression for people who SELECT lots of compressible
data over really slow network connections, but is that
a realistic
On Tue, Nov 8, 2011 at 2:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The fact of the matter is that in most situations where you want SSL,
ie links across insecure WANs, compression is a win. Testing a local
connection, as you seem to have done, is just about 100% irrelevant to
performance in
On 11/08/2011 09:34 AM, Tom Lane wrote:
Marko Kreenmark...@gmail.com writes:
On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenzlaurenz.a...@wien.gv.at wrote:
It is possible that this could cause a performance
regression for people who SELECT lots of compressible
data over really slow network
Andrew Dunstan and...@dunslane.net writes:
On 11/08/2011 09:34 AM, Tom Lane wrote:
There might be some argument for providing a client option to disable
compression, but it should not be forced, and it shouldn't even be the
default. But before adding YA connection option, I'd want to see some
On Tue, Nov 8, 2011 at 9:58 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
On 11/08/2011 09:34 AM, Tom Lane wrote:
There might be some argument for providing a client option to disable
compression, but it should not be forced, and it shouldn't even be the
On Tue, Nov 8, 2011 at 4:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Kreen mark...@gmail.com writes:
On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenz laurenz.a...@wien.gv.at wrote:
It is possible that this could cause a performance
regression for people who SELECT lots of compressible
data
Tom Lane wrote:
I distinctly recall us getting bashed a few years ago because there
wasn't any convenient way to turn SSL compression *on*. Now that SSL
finally does the sane thing by default, you want to turn it off?
The fact of the matter is that in most situations where you want SSL,
ie
Tom Lane wrote:
There might be some argument for providing a client option to disable
compression, but it should not be forced, and it shouldn't even be the
default. But before adding YA connection option, I'd want to see some
evidence that it's useful over non-local connections.
Here are
On Tue, Nov 08, 2011 at 04:59:02PM +0100, Albe Laurenz wrote:
Tom Lane wrote:
There might be some argument for providing a client option to disable
compression, but it should not be forced, and it shouldn't even be the
default. But before adding YA connection option, I'd want to see some
On Tue, Nov 08, 2011 at 04:19:02PM +0100, Albe Laurenz wrote:
Tom Lane wrote:
I distinctly recall us getting bashed a few years ago because there
wasn't any convenient way to turn SSL compression *on*. Now that SSL
finally does the sane thing by default, you want to turn it off?
The
On Tue, Nov 8, 2011 at 11:06 AM, k...@rice.edu k...@rice.edu wrote:
I think that JDBC and Npgsql should also support disabling compression.
That's the *real* problem here...
You're quite right that if we allow controlling this on the libpq
side, it is surely desirable to allow controlling this
On 2011-11-08 22:59, Albe Laurenz wrote:
In addition to the oprofile data I collected three times:
- the duration as shown in the server log
- the duration as shown by \timing
- the duration of the psql command as measured by time
[...]
I think this makes a good case for disabling
Jeroen Vermeulen j...@xs4all.nl writes:
Another reason why I believe compression is often used with encryption
is to maximize information content per byte of data: harder to guess,
harder to crack. Would that matter?
Yes, it would. There's a reason why the OpenSSL default is what it is.
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
The fact of the matter is that in most situations where you want SSL,
ie links across insecure WANs, compression is a win. Testing a local
connection, as you seem to have done, is just about 100% irrelevant to
performance in the real world.
I'm
38 matches
Mail list logo
