Re: BUG #5585: SSL problems with long COPYs
От | Karl Denninger |
---|---|
Тема | Re: BUG #5585: SSL problems with long COPYs |
Дата | |
Msg-id | 4C5587B0.8050005@denninger.net обсуждение исходный текст |
Ответ на | Re: BUG #5585: SSL problems with long COPYs (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
Tom Lane wrote:
I've also shut off SSL renegotiation for now and will leave it off until I can figure out what's up - if it breaks during my testing with renegotiation off (or not) I'll update here.
-- Karl
I've turned off SSL for now and the copy appears to be proceeding normally. I'll see if I can isolate this further once I have the replication stabilized again - I have a test box I can set up as a third node off one of the others on a higher-bandwidth connection, which will make testing this in some more detail easier and faster.Karl Denninger <karl@denninger.net> writes:Stefan Kaltenbrunner wrote:how exactly did you measure the 1GB?The reported copy table size in the SLON log. It exceeded 1GB for two of the tables the successfully came over before the error.Hmm, I'm not sure how Slony comes by that number, so this might or might not be meaningful. I agree with the other respondents that the symptom sounds exactly like broken renegotiation --- the earliest security patches to close the openssl CVE hole resulted in failures exactly like this whenever the server tried to force key renegotiation. You might check whether libssl was recently updated on either the server or client machine. regards, tom lane
I've also shut off SSL renegotiation for now and will leave it off until I can figure out what's up - if it breaks during my testing with renegotiation off (or not) I'll update here.
-- Karl
Вложения
В списке pgsql-bugs по дате отправления: