From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Campbell, Lance" <lance@illinois.edu>
cc: "pgsql-admin@postgresql.org" <pgsql-admin@postgresql.org>
Subject: Re: pg_dump error
In-reply-to: 
 <B75CD08C73BD3543B97E4EF3964B7D701FF53A92@CITESMBX1.ad.uillinois.edu>
References: 
 <B75CD08C73BD3543B97E4EF3964B7D701FF539B8@CITESMBX1.ad.uillinois.edu>
 <B75CD08C73BD3543B97E4EF3964B7D701FF53A92@CITESMBX1.ad.uillinois.edu>
Comments: In-reply-to "Campbell, Lance" <lance@illinois.edu>
 message dated "Mon, 20 Jul 2015 11:23:19 -0000"
Date: Mon, 20 Jul 2015 09:59:50 -0400
Message-ID: <14015.1437400790@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

"Campbell, Lance" <lance@illinois.edu> writes:
> As a follow-up I ran this command:
> pg_dump -U username -h localhost databasename -f databasename.20150720

> I get this in the console:
> pg_dump: [archiver (db)] query failed: SSL error: unexpected message
> pg_dump: [archiver (db)] query was: SET search_path = calendar, pg_catalog

That looks like you've run into the renegotiation bug that Red Hat
introduced in their last openssl patch:
https://bugzilla.redhat.com/show_bug.cgi?id=1234487

So basically things will work until you exceed a couple gigabytes of
traffic on the connection, and then bang.

The workaround we're recommending to people is to set
ssl_renegotiation_limit to zero (disable it) in postgresql.conf, as
renegotiation seems to create way more problems than it fixes (this
RH bug was very far from the first such problem, and it's not likely
to be the last either).

See recent discussions on pgsql-hackers, where it was more or less
agreed that we're going to remove the feature altogether in the future.

			regards, tom lane


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin