Hello,

I have a strange problem after adding a third node to my Slony cluster:

Up to now, I have a really simple Slony cluster: one master (node1), and one
slave (node2), which is subscribed to a unique set (set1). Everything
works fine for several years.
But now I have to add a second slave (node3) subscribed to the same set as
node2. So I followed the documentation [1] to configure it and then started the
slon daemon on node3.
I see in the slon log file that tables are correctly copied.
Ok, I wait some days (about 50GB of data to copy), but here is the weird
problem: tables on the new slave seem to grow infinitely, but without data in
it!

Example with the table “affectation”: normal size on master: 149MB.
But on the new slave:

    =# SELECT relname AS "relation", pg_size_pretty(pg_relation_size(C.oid)) AS "size"
      FROM pg_class C LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
      WHERE nspname NOT IN ('pg_catalog', 'information_schema') AND relname='affectation';
      relation   |  size  
    -------------+--------
     affectation | 22 GB
    (1 row)

But the table is empty:

    =# select * from affectation;
     affectation_id | datedu | dateau | passager | produitchoisi 
    ----------------+--------+--------+----------+---------------
    (0 rows)

If a do a VACUUM on slave, all tables size goes to zero.

In the log file, tables are recopied each 11/12 minutes: 

    # grep '"public"."affectation"' /var/log/slony1/node3-gesto2.log
    […]
    2014-08-01 12:06:14 CEST CONFIG remoteWorkerThread_1: prepare to copy table "public"."affectation"
    2014-08-01 12:06:20 CEST CONFIG remoteWorkerThread_1: copy table "public"."affectation"
    2014-08-01 12:06:20 CEST CONFIG remoteWorkerThread_1: Begin COPY of table "public"."affectation"
    NOTICE:  truncate of "public"."affectation" failed - doing delete
    2014-08-01 12:06:27 CEST CONFIG remoteWorkerThread_1: 124888731 bytes copied for table "public"."affectation"
    2014-08-01 12:06:31 CEST CONFIG remoteWorkerThread_1: 10.932 seconds to copy table "public"."affectation"
    2014-08-01 12:12:23 CEST CONFIG remoteWorkerThread_1: prepare to copy table "public"."affectation"
    2014-08-01 12:12:28 CEST CONFIG remoteWorkerThread_1: copy table "public"."affectation"
    2014-08-01 12:12:28 CEST CONFIG remoteWorkerThread_1: Begin COPY of table "public"."affectation"
    NOTICE:  truncate of "public"."affectation" failed - doing delete
    2014-08-01 12:12:35 CEST CONFIG remoteWorkerThread_1: 124892017 bytes copied for table "public"."affectation"
    2014-08-01 12:12:39 CEST CONFIG remoteWorkerThread_1: 10.954 seconds to copy table "public"."affectation"
    2014-08-01 12:18:33 CEST CONFIG remoteWorkerThread_1: prepare to copy table "public"."affectation"
    2014-08-01 12:18:38 CEST CONFIG remoteWorkerThread_1: copy table "public"."affectation"
    2014-08-01 12:18:38 CEST CONFIG remoteWorkerThread_1: Begin COPY of table "public"."affectation"
    NOTICE:  truncate of "public"."affectation" failed - doing delete
    2014-08-01 12:18:45 CEST CONFIG remoteWorkerThread_1: 124892761 bytes copied for table "public"."affectation"
    2014-08-01 12:18:49 CEST CONFIG remoteWorkerThread_1: 11.409 seconds to copy table "public"."affectation"
    […]

Note the correct table size (124742845 bytes) is copied.

To isolate the problem, I tried to create a new table, add it to a second set and
subscribe it to node3: everything ok, the copy process finish successfully. So
the problem seems to come from the set1 specifically.

All nodes run Slony 2.1.4 and PostgreSQL 9.3.4 under the same configuration.

Do you have any ideas about this problem?
It seems that Slony don't/can't acknowledge that tables are copied and so redo
the copy again and again.

[1] http://slony.info/documentation/2.1/modifyingthings.html#AEN1048

Thanks for any hint about that.
Regards,
-- 
Romain Dessort <rdessort at evolix.fr> GnuPG: 3072D/724BC532
Evolix − Hébergement et Infogérance Open Source http://www.evolix.fr/