Excerpts from Christopher Browne's message of 2014-08-01 18:52:58 +0200:
> I should expect that there'd be more in the log than that.
> 
> What you are showing seems perfectly appropriate; what I imagine is missing
> is that at the end, something is going wrong, the set is treated as NOT
> having subscribed successfully, and it (correctly, generally speaking)
> tries again a bit later.
> 
> Unfortunately, the "something going wrong" is some persistent problem, so
> the subscriptions to tables never succeed.
> 
> There should surely be more in the log.
> […]

You have right, there is indeed an error message is the log… I haven't
seen it before because of a to high debug level and a huge amount of
tables and sequences in the set.

    2014-08-03 16:17:52 CEST CONFIG remoteWorkerThread_1: copy table "public"."selectiondeproduit_produit_map"
    2014-08-03 16:17:53 CEST ERROR  remoteWorkerThread_1: "lock table "_replication".sl_config_lock;select "_replication".setAddTable_int(1, 170, '"public"."selectiondeproduit_produit_map"', 'selectiondeproduit_produit_map_idx', 'Table public.selectiondeproduit_produit_map with primary key'); " PGRES_FATAL_ERROR ERROR:  Slony-I: setAddTable_int(): table "public"."selectiondeproduit_produit_map" has no index selectiondeproduit_produit_map_idx

The index of selectiondeproduit_produit_map has apparently been renamed on node1 but Slony was not been notified about this change and the old name is still present in sl_tables table.
I going to fix that.

Thanks for your help about this straightforward problem!
-- 
Romain Dessort <rdessort at evolix.fr> GnuPG: 3072D/724BC532
Evolix − Hébergement et Infogérance Open Source http://www.evolix.fr/