Cédric Villemain wrote:
> Le Thursday 13 March 2008, Emanuel Petr a écrit :
>> Hi all,
>> we have problem to replicate 12 GB table.
>>
>> Note: Other smaller tables were replicated without problem.
>>
>> Here is what I see on "slave" node.
>> $ grep 'action"' /var/log/slony1/slon-db.log
>> DEBUG2 remoteWorkerThread_1: prepare to copy table "public"."action"
>> DEBUG2 remoteWorkerThread_1: copy table "public"."action"
>> DEBUG2 remoteWorkerThread_1: Begin COPY of table "public"."action"
>> NOTICE:  truncate of "public"."action" failed - doing delete
>>
>> DEBUG2 remoteWorkerThread_1: prepare to copy table "public"."action"
>> DEBUG2 remoteWorkerThread_1: copy table "public"."action"
>> DEBUG2 remoteWorkerThread_1: Begin COPY of table "public"."action"
>> NOTICE:  truncate of "public"."action" failed - doing delete
>> DEBUG2 remoteWorkerThread_1: 6584477358 bytes copied for table
>> "public"."action"
>>
>> DEBUG2 remoteWorkerThread_1: prepare to copy table "public"."action"
>> DEBUG2 remoteWorkerThread_1: copy table "public"."action"
>> DEBUG2 remoteWorkerThread_1: Begin COPY of table "public"."action"
>> NOTICE:  truncate of "public"."action" failed - doing delete
>> DEBUG2 remoteWorkerThread_1: 6587572735 bytes copied for table
>> "public"."action"
>>
>> DEBUG2 remoteWorkerThread_1: prepare to copy table "public"."action"
>> DEBUG2 remoteWorkerThread_1: copy table "public"."action"
>> DEBUG2 remoteWorkerThread_1: Begin COPY of table "public"."action"
>> NOTICE:  truncate of "public"."action" failed - doing delete
>>
>> I can't find any error message in the log.
> 
> I think you probably have made other try before.

No, there was only one try. It was aim to show you, that COPY action for 
this table is in a loop.

> 
> If for any reason, slony can not truncate the table before replicating it, it 
> delete every lines.

The table on "slave" node was blank before replication start.
And the message "truncate of ... failed - doing delete" appears for 
another tables, which were replicated without problem. So I don't think 
it's the problem.

There is problem only with bigger (over 10GB) tables.

> 
> 68GB/12GB give about 5 tests to replicate the table ?
> 
> I ommit the last versions of everything you are using.... (os, kernel, 
> postgres and slony)
> 
> You must truncate manualy the tables on the 'slave', then restarting your 
> replica from scratch.

And now I'm not able to work with this "badly" replicated table. Each 
command on this table hang up. Note: Slony is stopped.


> 
>> COPY event for this "big" table is in a loop and table size on "slave"
>> node is still growing.
>>
>> On "Master" node, the table size is 12GB.
>> On "Slave" node the tables size was 68GB before I have stopped the
>> replication.
>>
>>
>> -------------
>>
>> OS: Ubuntu 6.06.2 LTS , 2.6.15-29-amd64-server, x86_64
>>
>> DB: postgresql-8.1
>>
>> SLONY: Version: 1.2.9-2ubuntu0~dapper0
>>
>>
>> Detail of our problematic "12GB" table
>> =# \d+ action;
>>                                              Table "public.action"
>>     Column   |            Type             |
>> Modifiers                      | Description
>> ------------+-----------------------------+--------------------------------
>> ---------------------+------------- id         | integer                    
>> | not null default
>> nextval('action_id_seq'::regclass) |
>>   clientid   | integer                     |
>>
>>   action     | integer                     | not null
>>
>>   response   | integer                     |
>>
>>   startdate  | timestamp without time zone | not null default now()
>>
>>   clienttrid | character varying(128)      | not null
>>
>>   enddate    | timestamp without time zone |
>>
>>   servertrid | character varying(128)      |
>>
>> Indexes:
>>      "action_pkey" PRIMARY KEY, btree (id)
>>      "action_servertrid_key" UNIQUE, btree (servertrid)
>>      "action_action_idx" btree ("action")
>>      "action_clientid_idx" btree (clientid)
>>      "action_response_idx" btree (response)
>>      "action_startdate_idx" btree (startdate)
>> Foreign-key constraints:
>>      "action_action_fkey" FOREIGN KEY ("action") REFERENCES enum_action(id)
>>      "action_clientid_fkey" FOREIGN KEY (clientid) REFERENCES "login"(id)
>>      "action_response_fkey" FOREIGN KEY (response) REFERENCES
>> enum_error(id)
>>
>>
>> ---------------
>>
>> Does anyone have an idea what could be wrong?
>>
>> Thanks,
>> Petr
>> _______________________________________________
>> Slony1-general mailing list
>> Slony1-general at lists.slony.info
>> http://lists.slony.info/mailman/listinfo/slony1-general
> 
> 
>