Tory M Blue tmblue at gmail.com
Mon Dec 10 14:28:11 PST 2012
I'm back to it with debug of 4 on the source and the destination nodes.

Still failing

Destination:

Slon log:

2012-12-10 12:04:49 PST CONFIG remoteWorkerThread_1: 6525.754 seconds to
copy table "cls"."listings"
2012-12-10 12:04:49 PST CONFIG remoteWorkerThread_1: copy table
"cls"."customers"
2012-12-10 12:04:49 PST CONFIG remoteWorkerThread_1: Begin COPY of table
"cls"."customers"
2012-12-10 12:04:49 PST ERROR  remoteWorkerThread_1: "select
"_admissioncls".copyFields(8);"
2012-12-10 12:04:49 PST WARN   remoteWorkerThread_1: data copy for set 1
failed 1 times - sleep 15 seconds
2012-12-10 12:04:51 PST INFO   cleanupThread: 5961.364 seconds for
cleanupEvent()
2012-12-10 12:05:06 PST INFO   copy_set 1 - omit=f - bool=0
2012-12-10 12:05:06 PST INFO   omit is FALSE
2012-12-10 12:05:06 PST CONFIG version for "dbname=clsdb host=server
user=postgres password=SECURED is 90104
2012-12-10 12:05:07 PST DEBUG1 copy_set_1 "dbname=clsdb host=server
user=postgres password=SECURED": backend pid = 17092
2012-12-10 12:05:07 PST CONFIG remoteWorkerThread_1: connected to provider
DB

Postgres logs:

2012-12-10 12:04:51 PST admissionclsdb postgres [local] NOTICE:  Slony-I:
Logswitch to sl_log_2 initiated
2012-12-10 12:04:51 PST admissionclsdb postgres [local] CONTEXT:  SQL
statement "SELECT "_admissioncls".logswitch_start()"
2012-12-10 12:05:12 PST admissionclsdb postgres [local] LOG:  sending
cancel to blocking autovacuum PID 18620
2012-12-10 12:05:12 PST admissionclsdb postgres [local] DETAIL:  Process
18299 waits for AccessExclusiveLock on relation 17410 of database 16385.
2012-12-10 12:05:12 PST admissionclsdb postgres [local] STATEMENT:  lock
table "cls"."listings";
2012-12-10 12:05:12 PST    ERROR:  canceling autovacuum task
2012-12-10 12:05:12 PST    CONTEXT:  automatic vacuum of table
"admissionclsdb.cls.listings"
2012-12-10 12:05:12 PST admissionclsdb postgres [local] NOTICE:  truncate
of "cls"."autobodystyle" succeeded


Source:

There is nothing in the slon log that would tell me it's aware of this
client side restart or failure. Nothing in the postgres logs about an EOF
or anything.
Nothing in postgres log either that says there is an issue.

This is not a connection firewall thing. Since I have a table that will
take 4 hours and upon it's completion the process fails and starts over.
This file above is just about an hour, completes and then starts on another
before it says fail.

I'm wondering.. "Could" it be that for the first time, trying to replicate
from Postgres 9.1.4 to 9.1.6 there is an underlying issue? That is the only
difference in my various environments (the destination in this case is
running 9.1.6).

I'm up to trying anything, any ideas?

Thanks again and I appreciate the patience
Tory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20121210/5c4ac46f/attachment.html 


More information about the Slony1-general mailing list