the fastest fix is to modify test_slony_state.pl to not take into 
account events or confirms done for the initial SYNC on a receiver node.

Jan Wieck a écrit :
> On 5/20/2010 10:48 AM, Cyril Scetbon wrote:
>   
>> But this is a receiver and I saw in the code of  function 
>> generate_sync_event that it does not generate sync interval on a node 
>> which is not the origin of a set. That's why I presume there is no sync 
>> created except the one created at startup (mandatory) in syncThread_main :
>>     
>
>  From the CVS log:
>
>   
>> ----------------------------
>> revision 1.19
>> date: 2007-03-14 15:59:32 +0000;  author: cbbrowne;  state: Exp;  lines: +20 -6;
>> Reduce the quantity of spurious events generated:
>>
>> 1.  generate_sync_event() only needs to generate a SYNC on a node
>>     that is the origin for a set
>>
>> 2.  sync thread generates a SYNC when it starts; in later iterations,
>>     it will only generate a SYNC for its node if that node is the origin
>>     for a replication set
>>
>> Per discussions with Jan Wieck on 2007-02-09; this seemed an experiment
>> worth trying.  I tried it, and the tests run fine, so I'm committing this.
>> ----------------------------
>>     
>
> Seems we finally found a reason why this isn't such a good idea after 
> all. Question now is do we want to revert back to the default, where 
> slon's of pure receivers create useless SYNC events or not?
>
>
> Jan
>
>   

-- 
Cyril SCETBON