Re: BUG #5585: SSL problems with long COPYs

On 08/01/2010 08:33 AM, Karl Denninger wrote:
> Alex Hunsaker wrote:
>> On Sun, Aug 1, 2010 at 00:08, Karl Denninger<karl(at)denninger(dot)net> wrote:
>>
>>> The following bug has been logged online:
>>>
>>> Bug reference: 5585
>>> Logged by: Karl Denninger
>>> Email address:karl(at)denninger(dot)net
>>> PostgreSQL version: 8.4.4
>>> Operating system: FreeBSD 8.0
>>> Description: SSL problems with long COPYs
>>> Details:
>>>
>>> This is a copy of a message I posted this evening on the SLONY list.
>>>
>>> Synopsis: With SSL ON a large table copy containing a BYTEA field fails
>>> repeatedly a few minutes into the operation.
>>>
>>
>> My guess is its due to the server or client disabling ssl
>> renegotiation, per the docs:
>>
>> ssl_renegotiation_limit (integer)
>> Specifies how much data can flow over an SSL encrypted connection
>> before renegotiation of the session will take place. Renegotiation of
>> the session decreases the chance of doing cryptanalysis when large
>> amounts of data are sent, but it also carries a large performance
>> penalty. The sum of sent and received traffic is used to check the
>> limit. If the parameter is set to 0, renegotiation is disabled. The
>> default is 512MB.
>>
>> Note: SSL libraries from before November 2009 are insecure when using
>> SSL renegotiation, due to a vulnerability in the SSL protocol. As a
>> stop-gap fix for this vulnerability, some vendors also shipped SSL
>> libraries incapable of doing renegotiation. If any of these libraries
>> are in use on the client or server, SSL renegotiation should be
>> disabled.
>>
>> Id try setting that to 0 in your postgresql.conf and see if it still fails.
>>
>>
> I will attempt this but it is at least somewhat unlikely to be the
> cause, as prior to the failure two tables of over 1GB each did correctly
> transfer. They did not, however, have any binary (bytea) fields in them.

how exactly did you measure the 1GB? If that's the on-disk size of the
table (maybe even including indexes) it is entirely believable that the
amount of data transfered through COPY on the SSL-session was much less
than 512MB.
Given the symthoms reported I would agree with Alex on suspecting a
broken openssl library.

Stefan