I periodically experience the same issue as Mark reported (in exactly
the same setup and the same manner, though my sets include more tables
and sequences).

> If you add a WAIT FOR EVENT between those subscribe requests,
> that might do the trick...
Nope. It doesn't help. At least, it failed whenever I tried it. Placing two subscriptions into the same script also fails even if I separate them with WAIT FOR EVENT (and even if I add additional sleep N seconds after the WAIT). So I had to use a different approach, two separate scripts.

> If you submit the second SUBSCRIBE SET while the system's still
> working on the first one, then, at the time of submission, no,
> node won't *yet* be a forwarding subscriber.
Actually, the 2nd subscription frequently fails even it the 1st has already completed. What I usually do is, as said above, put each SUBSCRIBE in its own script. Then I run the 1st script (subscribe 2 to 1) and wait until it completes. Then I run the 2nd script that subscribes 3 to 2. Here, I believe the success is really a matter of timing. I mean, if I run the 2nd script say 2-5 sec after the 1st completed, it'd fail almost for sure. However, if I increase the pause to 10+ seconds it'd most likely succeed (numbers are more or less arbitrary).

Though I didn't investigate it much, but it seems to me that SUBSCRIBE SET command exits _before_ the all stages of subscriptions are completed.


Thanks.
Sergei




Christopher Browne wrote:
> Mark Hagger wrote:
>
>   
>> Hi,
>>
>> I've managed to get A replicating to B quite happily, but I'm having
>> trouble getting A -> B -> C.
>>
>> Full scripts are attached, but basically I'm doing:
>>
>> create set (id=1, origin=1, comment='Master');
>>
>> set add table (set id=1, origin=1, id=1, fully qualified name =
>> 'public.feed_details', comment='master feed_details table');
>>
>>
>> Starting the slon's on my 3 nodes
>>
>> and then trying:
>>
>>
>> subscribe set ( id = 1, provider = 1, receiver = 2, forward = yes);
>>
>> but when I try:
>>
>> subscribe set ( id = 1, provider = 2, receiver = 3, forward = no);
>>
>> It fails with:
>>
>> ERROR:  Slony-I: provider 2 is not an active forwarding node for
>> replication set 1
>>
>> I'm a little confused now, I would have thought the "forward=yes" on the
>> first subscribe makes it an active forwarding node?
>>
>> I'm sure I'm missing something blindingly obvious, but trawls through
>> the docs haven't shown anything I can see.  Any comments/suggestions
>> welcome.
>>  
>>
>>     
> Well, if you're missing the "apparently blindingly obvious," that can be
> a sign that the docs need some detail or another...
>
> At any rate, it sorta looks like your script tries to handle all the
> subscriptions in one swell foop, and that's probably what's not working.
>
> If you submit the second SUBSCRIBE SET while the system's still working
> on the first one, then, at the time of submission, no, node won't *yet*
> be a forwarding subscriber.
>
> If you add a WAIT FOR EVENT between those subscribe requests, that might
> do the trick...
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general
>