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<k...@denninger.net> >>> wrote: >>> >>>> The following bug has been logged online: >>>> >>>> Bug reference: 5585 >>>> Logged by: Karl Denninger >>>> Email address:k...@denninger.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
<<attachment: karl.vcf>>
-- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs