Stefan Kaltenbrunner wrote:
> 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.
The reported copy table size in the SLON log. It exceeded 1GB for two
of the tables the successfully came over before the error.
-- Karl