Re: BUG #5585: SSL problems with long COPYs

Tom Lane wrote:
> Karl Denninger <karl(at)denninger(dot)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.
>
I set the ssl_renegotiation off and the copy is now being attempted (and
is well past where it failed before) with SSL on.

There's a second problem in that SLONY appears to have a memory
management issue that I've tickled with a COPY of this particular table,
and it's a bad one - it may preclude me from being able to resync at all
- but that's not Postgres' fault.

Looks like this bug report can be closed as the issue does not appear to
be yours beyond the SSL issue that is documented.

(Whether Postgress 9's internal replication will solve this for me when
it is released is something I'm not sure about - I think the answer is
"no", since if I'm reading the docs correctly Postgres 9 requires that
both master and slave be in sync via some other method before the
replication is enabled - that is, it's not capable of taking a "raw"
(populated with empty tables or not) new system and bringing it into
sync and then replicating from there. That's a major problem in a
"live" environment if there's a failure of some sort and you want to
bring the system that failed back into the cluster......)

-- Karl