Tory M Blue wrote: > Postgres 9.1.4 slon 2.1.1 > -and- > Postgres 9.1.6 slon 2.1.2
If it is possible, it never hurts to rule out bugs for which fixes are already available in production releases: http://www.postgresql.org/support/versioning/ > Symptoms, slon immediately dies after transferring the biggest table in the > set Dies? What does that mean, exactly? > 1224459-2013-01-11 14:21:10 PST CONFIG remoteWorkerThread_1: 5760.913 > seconds to copy table "cls"."listings" > 1224560-2013-01-11 14:21:10 PST CONFIG remoteWorkerThread_1: copy table > "cls"."customers" > 1224642-2013-01-11 14:21:10 PST CONFIG remoteWorkerThread_1: Begin COPY of > table "cls"."customers" > 1224733-2013-01-11 14:21:10 PST ERROR remoteWorkerThread_1: "select > "_admissioncls".copyFields(8);" <--- this has the proper data > 1224827:2013-01-11 14:21:10 PST WARN remoteWorkerThread_1: data copy for > set 1 failed 1 times - sleep 15 seconds What, specifically, can cause those that set of messages from Slony? > I get no errors in the postgres logs, there is no network disconnect and > since I can do a copy over the wire that completes, I'm at a loss. I don't > know what to look at, what to look for or what to do. Obviously this is > the wrong place to slon issues. It is hard to make much of a guess without more data. I recommend looking over this page for ideas: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems ... but in particular I think grabbing the contents of pg_stat_activity (using a superuser login) and pg_locks as soon as you feel it has died will be helpful. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers