Tom Lane wrote:
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.
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
