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