Tory M Blue wrote:
Postgres 9.1.4 slon 2.1.1
-and-
Postgres 9.1.6 slon 2.1.2
Postgres 9.1.4 slon 2.1.1
-and-
Postgres 9.1.6 slon 2.1.2
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 fromset
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
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 recommendsince 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.
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
