On 5/21/2010 4:46 AM, Cyril Scetbon wrote:
> 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.

Wouldn't that mask problems where confirmations don't flow properly back 
to non-origin nodes?

As long as they don't produce any events, that's not much of a problem. 
But it is better to discover such before attempting to use that node as 
a failover target or the like.


Jan


> 
> 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
>>
>>   
> 


-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin