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.


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


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