Tory M Blue wrote:

Postgres 9.1.4 slon 2.1.1
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:
Symptoms, slon immediately dies after transferring the biggest table in the
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
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
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:

... 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.


Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 2 | next ›
Discussion Overview
grouppgsql-hackers @
postedJan 12, '13 at 5:49a
activeJan 13, '13 at 10:49p

2 users in discussion

Tory M Blue: 1 post Kevin Grittner: 1 post



site design / logo © 2021 Grokbase