Skip to content
  • Andrei Elkin's avatar
    d7abb06d
    BUG#16594095 · d7abb06d
    Andrei Elkin authored
    Post-push refinement to fix a valgrind issue.
    The basic pushed patch did not expect a block of
     if (!ret_worker->checkpoint_notified) {}
    be executed multiple times during scheduling of one group.
    In fact it should have been left intact to continue to be executed at T-event
    time that guarantees its single time run.
    And that is restored, that is the former patch part is reverted.
    
    As the matter of fact the physical coordinates were unknown to the Worker 
    only during time of the first transaction scheduling upon master binlog
    rotation or the very first one at MTS start.
    Information about the master binlog at such points is passed to the Worker
    now via augmented notification mechanism.
    The new notification is light as in implementation so in terms of execution
    (is supposed to be pretty rare) and never more that once during one transaction
    scheduling (as asserted in the DBUG version of the patch).
    
    Attention to rpl_conflicts.test is paid to sort out 
    rpl_{row,stm}conflicts.test failing on PB2.
    d7abb06d
    BUG#16594095
    Andrei Elkin authored
    Post-push refinement to fix a valgrind issue.
    The basic pushed patch did not expect a block of
     if (!ret_worker->checkpoint_notified) {}
    be executed multiple times during scheduling of one group.
    In fact it should have been left intact to continue to be executed at T-event
    time that guarantees its single time run.
    And that is restored, that is the former patch part is reverted.
    
    As the matter of fact the physical coordinates were unknown to the Worker 
    only during time of the first transaction scheduling upon master binlog
    rotation or the very first one at MTS start.
    Information about the master binlog at such points is passed to the Worker
    now via augmented notification mechanism.
    The new notification is light as in implementation so in terms of execution
    (is supposed to be pretty rare) and never more that once during one transaction
    scheduling (as asserted in the DBUG version of the patch).
    
    Attention to rpl_conflicts.test is paid to sort out 
    rpl_{row,stm}conflicts.test failing on PB2.
Loading