Venkatraju wrote:
> Hi,
> 
> I am trying to setup a 2 node Slony cluster on PostgreSQL 8.4.1 using
> Slony 1.2.20 on CentOS 5.4. Setting up subscriber was stuck and timed
> out during the COPY process.

Is anything holding locks on your table2?
Do you have any long running transactions?


> 
> 2010-05-10 15:41:42 PDT [24765] DEBUG2 remoteWorkerThread_1:  nodeon73 is 0
> NOTICE:  truncate of "public"."table1" succeeded
> 2010-05-10 15:41:42 PDT [24765] DEBUG2 remoteWorkerThread_1: 96 bytes
> copied for table "public"."table1"
> 2010-05-10 15:41:42 PDT [24765] DEBUG2 remoteWorkerThread_1: 0.290
> seconds to copy table "public"."table1"
> 2010-05-10 15:41:42 PDT [24765] DEBUG2 remoteWorkerThread_1: copy
> table "public"."table2"
> 2010-05-10 15:41:42 PDT [24765] DEBUG3 remoteWorkerThread_1: table
> "public"."table2" does not require Slony-I serial key
> 2010-05-10 15:41:42 PDT [24765] DEBUG2 remoteWorkerThread_1: Begin
> COPY of table "public"."table2"
> 2010-05-10 15:41:42 PDT [24765] DEBUG2 remoteWorkerThread_1:  nodeon73 is 0
> NOTICE:  truncate of "public"."table2" failed - doing delete
> 2010-05-10 15:41:48 PDT [24765] DEBUG2 localListenThread: Received
> event 2,2 SYNC
> 2010-05-10 15:42:09 PDT [24765] DEBUG2 remoteListenThread_1: LISTEN
> 2010-05-10 15:42:11 PDT [24765] DEBUG2 remoteListenThread_1: queue
> event 1,7633 SYNC
> 2010-05-10 15:42:11 PDT [24765] DEBUG2 remoteListenThread_1: UNLISTEN
> 
> It is almost as if it is stuck copying table2 which has just one row
> of data. Replication setup was aborted since there was no progress for
> 10 minutes.
> 
> Not sure if this is related, but the only log line in Postgres logs at
> about the same time is:
> 2010-05-10 15:41:14 PDT superuser mydb 24720 4be88b8a.6090
> 19000WARNING:  type attribute "externallength" not recognized
> 
> PostgreSQL logs when the replication setup was aborted:
> 2010-05-10 15:51:25 PDT superuser mydb 24774 4be88b8e.60c6 19009ERROR:
>  unexpected EOF on client connection
> 2010-05-10 15:51:25 PDT superuser mydb 24774 4be88b8e.60c6
> 19009CONTEXT:  COPY table2, line 1
> 2010-05-10 15:51:25 PDT superuser mydb 24774 4be88b8e.60c6
> 19009STATEMENT:  select "_mycluster".prepareTableForCopy(72); copy
> "public"."table2" ("id","name","title","logo","org_id") from stdin;
> 2010-05-10 15:51:25 PDT superuser mydb 24774 4be88b8e.60c6 19009LOG:
> could not send data to client: Broken pipe
> 
> Looks like it was stuck in prepareTableForCopy function. Replication
> setup succeeded when the operation was repeated. Has anyone seen this
> before? Any ideas about what could cause this?
> 
> Regards,
> Venkat
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general


-- 
Steve Singer
Afilias Canada
Data Services Developer
416-673-1142