Jan Wieck a écrit :
> On 5/21/2010 8:22 AM, Cyril Scetbon wrote:
>   
>> Jan Wieck a écrit :
>>     
>>> 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?
>>>   
>>>       
>> if we don't take into account the event (SYNC) created on a non-origin 
>> node but confirmed by others what could it mask ? everything worked fine 
>> and as this the last event it won't be removed (and so live longer than 
>> the interval defined in test-slony-state)
>>     
>>> 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.
>>>   
>>>       
>> in this case the event must have been confirmed to not be taken into 
>> account.
>>     
>
> I don't care much about that one old event. It does no harm other than 
> currently confusing test_slony_state. What I worry about is attempting 
> to failover in the case of emergency with an only half functioning path 
> network.
>   
I don't really understand the issue you're talking about... Certainly 
I've a weak knowledge of your code :)
You're talking about missing errors in network cause there are no SYNC 
generated on a receiver ? If yes, if it confirms events from others it's 
not enough to say that everything works ?
>
> Jan
>
>
>   
>>> 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
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>   
>>>       
>
>
>   

-- 
Cyril SCETBON