List:Commits« Previous MessageNext Message »
From:He Zhenxing Date:September 14 2009 9:54am
Subject:Re: bzr commit into mysql-pe branch (alfranio.correia:3512) WL#2687
View as plain text  
Alfranio Correia wrote:
> Alfranio Correia wrote:
> 
> Hi Jasonh,
> 
> I like your idea:
> 
> "I'm thinking about maybe we can use the command flags setupped in
> init_update_queries(), such as CF_AUTO_COMMIT_TRANS, or maybe we can
> define a new flag."
> 
> 
> Maybe we could create a new flag and remove the "direct" flag from
> the MYSQL_BIN_LOG::write(). Note that this is orthogonal to the
> call to thd->binlog_start_trans_and_stmt(). However, if you both
> want we can avoid calling such method when processing a DDL. I don't
> have a strong opinion. And if we adopt the flag, I think we should
> not call  thd->binlog_start_trans_and_stmt() when processing DDLs.
> 

It looks CF_AUTO_COMMIT_TRANS is set and only set for DDLs, if we can
make sure about this, then we can reuse this flag and avoid adding a new
one.

And I still think that thd->binlog_start_trans_and_stmt() should not be
called for events that will be written directly. Because it will
register binlog_ht to the statement/transaction, and then at the end of
the DDL statement, ha_trans_commit will be called for this statement,
and increases Handler_commit for DDL statements.

> Andrei, what do you think about Jasonh's suggestion?
> 
> 
> Cheers. 
> 
> 
> > Hi Jasonh,
> >
> > I think we should discuss this. The only reason to handle them
> > differently is because
> > the NDB is expecting that such statements are written directly to the
> > binary log.
> > However, theoretically speaking there is no reason to handle them
> > differently.
> >
> > Furthermore, thd->binlog_start_trans_and_stmt() is being called for all
> > statements since BUG#43929.
> >
> > Cheers.
> >
> > He Zhenxing wrote:
> >   
> >> Alfranio Correia wrote:
> >>   
> >>     
> >>> I forgot to put Andrei in cc.
> >>>
> >>> Cheers.
> >>>
> >>> Alfranio Correia wrote:
> >>>     
> >>>       
> >>>> Hi Jasonh,
> >>>>
> >>>> Thank you very much.
> >>>> This is exactly my main concern about the patch.
> >>>> I agree with the suggestions on the test case.
> >>>> Can you point to a place (manual/test case) where I can find all or
> >>>> almost all DDLs?
> >>>> Do you have a suggestion on how I could verify if a DDL was written
> >>>> directly to the binary log?
> >>>> See other comments in-line.
> >>>>
> >>>>
> >>>> Cheers.
> >>>>
> >>>>
> >>>> He Zhenxing wrote:
> >>>>   
> >>>>       
> >>>>         
> >>>>> Hi Alfranio,
> >>>>>
> >>>>> Thank you for the **great** work!
> >>>>>
> >>>>> Mainly I have only one concerns about the fix, that is the
> changes of
> >>>>> Handler_commit/prepare values in commit.inc. I think many of
> these
> >>>>> changes are suspicious. And I think the problem stems in that
> when
> >>>>> AUTOCOMMIT is 0, DDLs are not recognized and are not written
> directly
> >>>>> into binlog. This also suggest that probably need a test case to
> check
> >>>>> if DDLs are written directly to binlog file in all
> circumstances.
> >>>>>
> >>>>> Please see inline comments below for more information about
> this.
> >>>>>
> >>>>> Alfranio Correia wrote:
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>>>> #At
> file:///home/acorreia/workspace.sun/repository.mysql/bzrwork/bug-40278/mysql-pe-wl2687-push/
> based on revid:alfranio.correia@stripped
> >>>>>>
> >>>>>>  3512 Alfranio Correia	2009-09-11
> >>>>>>       WL#2687
> >>>>>>     
> >>>>>>       
> >>>>>>           
> >>>>>>             
> >>>>> [ snip ]
> >>>>>
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>>>> === modified file 'mysql-test/include/commit.inc'
> >>>>>> --- a/mysql-test/include/commit.inc	2009-08-26 23:32:54
> +0000
> >>>>>> +++ b/mysql-test/include/commit.inc	2009-09-10 23:48:16
> +0000
> >>>>>> @@ -409,7 +409,7 @@ flush status;
> >>>>>>  --echo # 1. Read-only statement: SELECT
> >>>>>>  --echo #
> >>>>>>  select * from t1;
> >>>>>> -call p_verify_status_increment(1, 0, 1, 0);
> >>>>>> +call p_verify_status_increment(3, 0, 3, 0);
> >>>>>>     
> >>>>>>       
> >>>>>>           
> >>>>>>             
> >>>>> This is very strange! After investigate this more, it turns out
> that
> >>>>> after FLUSH STATUS, the count of Handler_commit is 2 instead of
> 0, which
> >>>>> is absolutely wrong. And I found the reason of this is that in
> >>>>> mysql_bin_log.write, FLUSH STATUS is considered as a DDL if
> AUTOCOMMIT
> >>>>> is 0, and thus the binlog is not written directly to binlog
> file, and:
> >>>>>   thd->binlog_start_trans_and_stmt()
> >>>>> is called for FLUSH STATUS, which I think is not correct.
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>> I see your point but we need to call
> thd->binlog_start_trans_and_stmt()
> >>>> regardless of the type of the statement. And when
> >>>>       
> >>>>         
> >> I think for DDLs and other cases that we should write directly to
> >> binlog, thd->binlog_start_trans_and_stmt() should be not be called, and
> >> I think this is the case for DDLs when AUTOCOMMIT is 1.
> >>
> >>   
> >>     
> >>>> thd->binlog_start_trans_and_stmt() is called, we don't know if
> you are
> >>>> about to execute a DDL or a DML. It would be great if the parser
> provided
> >>>> such information but it doesn't.
> >>>>       
> >>>>         
> >> I'm thinking about maybe we can use the command flags setupped in
> >> init_update_queries(), such as CF_AUTO_COMMIT_TRANS, or maybe we can
> >> define a new flag.
> >>
> >>   
> >>     
> >>>>   
> >>>>       
> >>>>         
> >>>>> Please see below for similar issues.
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>> ok.
> >>>>   
> >>>>       
> >>>>         
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>>>>  commit;
> >>>>>>  call p_verify_status_increment(1, 0, 1, 0);
> >>>>>>  
> >>>>>> @@ -538,7 +538,7 @@ begin
> >>>>>>    return 2;
> >>>>>>  end|
> >>>>>>  delimiter ;|
> >>>>>> -call p_verify_status_increment(0, 0, 0, 0);
> >>>>>> +call p_verify_status_increment(2, 0, 2, 0);
> >>>>>>  
> >>>>>>     
> >>>>>>       
> >>>>>>           
> >>>>>>             
> >>>>> This is another example, the DDL (create function) is not
> written
> >>>>> directly to binlog file when AUTOCOMMIT is 0.
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>> ok.
> >>>>   
> >>>>       
> >>>>         
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>>>>  --echo # 16. A function changes non-trans-table.
> >>>>>>  --echo #
> >>>>>> @@ -547,9 +547,9 @@ call p_verify_status_increment(0, 0, 0,
> 
> >>>>>>  --echo # the binary log. 
> >>>>>>  --echo #
> >>>>>>  select f1();
> >>>>>> -call p_verify_status_increment(0, 0, 1, 0);
> >>>>>> +call p_verify_status_increment(1, 0, 1, 0);
> >>>>>>  commit;
> >>>>>> -call p_verify_status_increment(0, 0, 1, 0);
> >>>>>> +call p_verify_status_increment(1, 0, 1, 0);
> >>>>>>  
> >>>>>>  --echo # 17. Read-only statement, a function changes
> non-trans-table.
> >>>>>>  --echo #
> >>>>>> @@ -558,9 +558,9 @@ call p_verify_status_increment(0, 0, 1,
> 
> >>>>>>  --echo # the binary log. 
> >>>>>>  --echo #
> >>>>>>  select f1() from t1;
> >>>>>> -call p_verify_status_increment(1, 0, 2, 0);
> >>>>>> +call p_verify_status_increment(2, 0, 2, 0);
> >>>>>>  commit;
> >>>>>> -call p_verify_status_increment(1, 0, 2, 0);
> >>>>>> +call p_verify_status_increment(2, 0, 2, 0);
> >>>>>>  
> >>>>>>  --echo # 18. Read-write statement: UPDATE, change 0
> (transactional) rows. 
> >>>>>>  --echo #
> >>>>>> @@ -579,7 +579,7 @@ call p_verify_status_increment(2, 0, 2,
> 
> >>>>>>  drop table t2;
> >>>>>>  set sql_mode=no_engine_substitution;
> >>>>>>  create temporary table t2 (a int);
> >>>>>> -call p_verify_status_increment(0, 0, 0, 0);
> >>>>>> +call p_verify_status_increment(3, 0, 2, 0);
> >>>>>>     
> >>>>>>       
> >>>>>>           
> >>>>>>             
> >>>>> Another one.
> >>>>>
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>> ok.
> >>>>   
> >>>>       
> >>>>         
> >>>>>>  set sql_mode=default;
> >>>>>>  --echo # 19. A function changes temp-trans-table.
> >>>>>>  --echo #
> >>>>>> @@ -608,7 +608,7 @@ call p_verify_status_increment(2, 0, 1,
> 
> >>>>>>  --echo #
> >>>>>>  alter table t2 add column b int default 5;
> >>>>>>  --echo # A commit is done internally by ALTER. 
> >>>>>> -call p_verify_status_increment(2, 0, 2, 0);
> >>>>>> +call p_verify_status_increment(4, 0, 2, 0);
> >>>>>>     
> >>>>>>       
> >>>>>>           
> >>>>>>             
> >>>>> and here.
> >>>>>
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>>>>  commit;
> >>>>>>  --echo # There is nothing left to commit
> >>>>>>  call p_verify_status_increment(0, 0, 0, 0);
> >>>>>> @@ -620,7 +620,7 @@ call p_verify_status_increment(0, 0, 0,
> 
> >>>>>>  --echo # 24. DDL: TRUNCATE TEMPORARY TABLE
> >>>>>>  --echo
> >>>>>>  truncate table t2;
> >>>>>> -call p_verify_status_increment(4, 0, 4, 0);
> >>>>>> +call p_verify_status_increment(2, 0, 2, 0);
> >>>>>>     
> >>>>>>       
> >>>>>>           
> >>>>>>             
> >>>>> here.
> >>>>>
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>>>>  commit;
> >>>>>>  --echo # There is nothing left to commit
> >>>>>>  call p_verify_status_increment(0, 0, 0, 0);
> >>>>>> @@ -636,9 +636,9 @@ call p_verify_status_increment(2, 0, 1,
> 
> >>>>>>  --echo # 25. DDL: DROP TEMPORARY TABLE, does not start a
> transaction
> >>>>>>  --echo #
> >>>>>>  drop temporary table t2;
> >>>>>> -call p_verify_status_increment(0, 0, 0, 0);
> >>>>>> +call p_verify_status_increment(1, 0, 0, 0);
> >>>>>>  commit;
> >>>>>> -call p_verify_status_increment(0, 0, 0, 0);
> >>>>>> +call p_verify_status_increment(1, 0, 0, 0);
> >>>>>>  
> >>>>>>  --echo # 26. Verify that SET AUTOCOMMIT issues an implicit
> commit
> >>>>>>  --echo #
> >>>>>> @@ -683,7 +683,7 @@ call p_verify_status_increment(1, 0, 1,
> 
> >>>>>>  --echo # 28. Read-write statement: DO
> >>>>>>  --echo #
> >>>>>>  create table t2 (a int);
> >>>>>> -call p_verify_status_increment(0, 0, 0, 0);
> >>>>>> +call p_verify_status_increment(2, 0, 2, 0);
> >>>>>>     
> >>>>>>       
> >>>>>>           
> >>>>>>             
> >>>>> here
> >>>>>
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>>>>  do (select f1() from t1 where a=2);
> >>>>>>  call p_verify_status_increment(2, 2, 2, 2);
> >>>>>>  commit;
> >>>>>> @@ -723,15 +723,15 @@ call p_verify_status_increment(4, 4,
> 4, 
> >>>>>>  create table t3 select a from t2;
> >>>>>>  call p_verify_status_increment(4, 4, 4, 4);
> >>>>>>  alter table t3 add column (b int);
> >>>>>> -call p_verify_status_increment(2, 0, 2, 0);
> >>>>>> +call p_verify_status_increment(4, 0, 4, 0);
> >>>>>>     
> >>>>>>       
> >>>>>>           
> >>>>>>             
> >>>>> here
> >>>>>
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>>>>  alter table t3 rename t4;
> >>>>>>  call p_verify_status_increment(4, 4, 4, 4);
> >>>>>>  rename table t4 to t3;
> >>>>>> -call p_verify_status_increment(0, 0, 0, 0);
> >>>>>> +call p_verify_status_increment(2, 0, 2, 0);
> >>>>>>     
> >>>>>>       
> >>>>>>           
> >>>>>>             
> >>>>> here
> >>>>>
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>>>>  truncate table t3;
> >>>>>> -call p_verify_status_increment(4, 4, 4, 4);
> >>>>>> +call p_verify_status_increment(2, 2, 2, 2);
> >>>>>>     
> >>>>>>       
> >>>>>>           
> >>>>>>             
> >>>>> here
> >>>>>
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>>>>  create view v1 as select * from t2;
> >>>>>> -call p_verify_status_increment(2, 0, 2, 0);
> >>>>>> +call p_verify_status_increment(4, 0, 4, 0);
> >>>>>>     
> >>>>>>       
> >>>>>>           
> >>>>>>             
> >>>>> here
> >>>>>
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>>>>  check table t1;
> >>>>>>  call p_verify_status_increment(2, 0, 2, 0);
> >>>>>>  --echo # Sic: after this bug is fixed, CHECK leaves no
> pending transaction
> >>>>>> @@ -742,7 +742,7 @@ call p_verify_status_increment(6, 0, 6,
> 
> >>>>>>  commit;
> >>>>>>  call p_verify_status_increment(0, 0, 0, 0);
> >>>>>>  drop view v1;
> >>>>>> -call p_verify_status_increment(0, 0, 0, 0);
> >>>>>> +call p_verify_status_increment(2, 0, 2, 0);
> >>>>>>  
> >>>>>>     
> >>>>>>       
> >>>>>>           
> >>>>>>             
> >>>>> and here.
> >>>>>
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>>>>  --echo #
> >>>>>>  --echo # Cleanup
> >>>>>>     
> >>>>>>       
> >>>>>>           
> >>>>>>             
> >>>>> [ snip ]
> >>>>>
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>>>> -bool MYSQL_BIN_LOG::write(Log_event *event_info)
> >>>>>> +bool MYSQL_BIN_LOG::write(Log_event *event_info, bool
> direct)
> >>>>>>  {
> >>>>>>    THD *thd= event_info->thd;
> >>>>>>    bool error= 1;
> >>>>>>    DBUG_ENTER("MYSQL_BIN_LOG::write(Log_event *)");
> >>>>>> +  binlog_cache_data *cache_data= 0;
> >>>>>>  
> >>>>>>    if (thd->binlog_evt_union.do_union)
> >>>>>>    {
> >>>>>> @@ -5928,27 +6035,22 @@ bool MYSQL_BIN_LOG::write(Log_event
> *eve
> >>>>>>        We will log the function call to the binary log on
> function exit
> >>>>>>      */
> >>>>>>      thd->binlog_evt_union.unioned_events= TRUE;
> >>>>>> -    thd->binlog_evt_union.unioned_events_trans |=
> event_info->cache_stmt;
> >>>>>> +    thd->binlog_evt_union.unioned_events_trans |= 
> >>>>>> +      event_info->is_trans_event();
> >>>>>>      DBUG_RETURN(0);
> >>>>>>    }
> >>>>>>  
> >>>>>>    /*
> >>>>>> -    Flush the pending rows event to the transaction cache
> or to the
> >>>>>> -    log file.  Since this function potentially aquire the
> LOCK_log
> >>>>>> -    mutex, we do this before aquiring the LOCK_log mutex in
> this
> >>>>>> -    function.
> >>>>>> -
> >>>>>>      We only end the statement if we are in a top-level
> statement.  If
> >>>>>>      we are inside a stored function, we do not end the
> statement since
> >>>>>>      this will close all tables on the slave.
> >>>>>>    */
> >>>>>>    bool const end_stmt=
> >>>>>>      thd->locked_tables_mode &&
> thd->lex->requires_prelocking();
> >>>>>> -  if (thd->binlog_flush_pending_rows_event(end_stmt))
> >>>>>> +  if (thd->binlog_flush_pending_rows_event(end_stmt,
> >>>>>> +                                          
> event_info->is_trans_event()))
> >>>>>>      DBUG_RETURN(error);
> >>>>>>  
> >>>>>> -  pthread_mutex_lock(&LOCK_log);
> >>>>>> -
> >>>>>>    /*
> >>>>>>       In most cases this is only called if 'is_open()' is
> true; in fact this is
> >>>>>>       mostly called if is_open() *was* true a few
> instructions before, but it
> >>>>>> @@ -5956,7 +6058,6 @@ bool MYSQL_BIN_LOG::write(Log_event
> *eve
> >>>>>>    */
> >>>>>>    if (likely(is_open()))
> >>>>>>    {
> >>>>>> -    IO_CACHE *file= &log_file;
> >>>>>>  #ifdef HAVE_REPLICATION
> >>>>>>      /*
> >>>>>>        In the future we need to add to the following if
> tests like
> >>>>>> @@ -5966,45 +6067,57 @@ bool MYSQL_BIN_LOG::write(Log_event
> *eve
> >>>>>>      const char *local_db= event_info->get_db();
> >>>>>>      if ((thd && !(thd->options &
> OPTION_BIN_LOG)) ||
> >>>>>>  	(!binlog_filter->db_ok(local_db)))
> >>>>>> -    {
> >>>>>> -      pthread_mutex_unlock(&LOCK_log);
> >>>>>>        DBUG_RETURN(0);
> >>>>>> -    }
> >>>>>>  #endif /* HAVE_REPLICATION */
> >>>>>> +    IO_CACHE *file= NULL;
> >>>>>>  
> >>>>>>      /*
> >>>>>> -      Should we write to the binlog cache or to the binlog
> on disk?
> >>>>>> -      Write to the binlog cache if:
> >>>>>> -      - it is already not empty (meaning we're in a
> transaction; note that the
> >>>>>> -     present event could be about a non-transactional
> table, but still we need
> >>>>>> -     to write to the binlog cache in that case to handle
> updates to mixed
> >>>>>> -     trans/non-trans table types the best possible in
> binlogging)
> >>>>>> -      - or if the event asks for it (cache_stmt == TRUE).
> >>>>>> +      This is an ugly hack that must be removed as soon as
> we fix a bug in
> >>>>>> +      NDB. In a nutshell, this  means that we should use
> the binary log 
> >>>>>> +      directly if we are processing a DDL.
> >>>>>>      */
> >>>>>> -    if (opt_using_transactions && thd)
> >>>>>> +    bool ddl=
> >>>>>> +      (!thd->in_multi_stmt_transaction() &&
> >>>>>> +       !thd->transaction.stmt.modified_non_trans_table
> &&
> >>>>>> +       !stmt_has_updated_trans_table(thd) &&
> >>>>>> +       !trans_has_updated_trans_table(thd) &&
> >>>>>> +       !event_info->is_trans_event());
> >>>>>> +
> >>>>>>     
> >>>>>>       
> >>>>>>           
> >>>>>>             
> >>>>> When AUTOCOMMIT=0, DDLs like FLUSH STATUS will not be considered
> as DDL
> >>>>> because the check of thd->in_multi_stmt_transaction().
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>> Andrei requested to remove the code above and use the direct flag
> to
> >>>> decide on
> >>>> how to write the statement. So every DDL has the direct flag equals
> to true.
> >>>>   
> >>>>       
> >>>>         
> >> See above comments.
> >>
> >>   
> >>     
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>>>> +    direct= direct || ddl;
> >>>>>> +
> >>>>>> +    if (direct)
> >>>>>> +    {
> >>>>>> +      file= &log_file;
> >>>>>> +      pthread_mutex_lock(&LOCK_log);
> >>>>>> +    }
> >>>>>> +    else
> >>>>>>      {
> >>>>>>        if (thd->binlog_setup_trx_data())
> >>>>>>          goto err;
> >>>>>>  
> >>>>>> -      binlog_trx_data *const trx_data=
> >>>>>> -        (binlog_trx_data*) thd_get_ha_data(thd,
> binlog_hton);
> >>>>>> -      IO_CACHE *trans_log= &trx_data->trans_log;
> >>>>>> -      my_off_t trans_log_pos= my_b_tell(trans_log);
> >>>>>> -      if (event_info->get_cache_stmt() || trans_log_pos
> != 0 ||
> >>>>>> -          stmt_has_updated_trans_table(thd))
> >>>>>> +      binlog_cache_mngr *const cache_mngr=
> >>>>>> +        (binlog_cache_mngr*) thd_get_ha_data(thd,
> binlog_hton);
> >>>>>> +
> >>>>>> +      if (thd->current_stmt_binlog_row_based)
> >>>>>>        {
> >>>>>> -        DBUG_PRINT("info", ("Using trans_log: cache: %d,
> trans_log_pos: %lu",
> >>>>>> -                           
> event_info->get_cache_stmt(),
> >>>>>> -                            (ulong) trans_log_pos));
> >>>>>> -        thd->binlog_start_trans_and_stmt();
> >>>>>> -        file= trans_log;
> >>>>>> +        file= event_info->is_trans_event() ?
> &cache_mngr->trx_cache.cache_log :
> >>>>>> +                                            
> &cache_mngr->stmt_cache.cache_log;
> >>>>>> +        cache_data=  event_info->is_trans_event() ?
> &cache_mngr->trx_cache : 
> >>>>>> +                                                   
> &cache_mngr->stmt_cache;
> >>>>>>        }
> >>>>>> -      /*
> >>>>>> -        TODO as Mats suggested, for all the cases above
> where we write to
> >>>>>> -        trans_log, it sounds unnecessary to lock LOCK_log.
> We should rather
> >>>>>> -        test first if we want to write to trans_log, and if
> not, lock
> >>>>>> -        LOCK_log.
> >>>>>> -      */
> >>>>>> +      else if (cache_mngr->trx_cache.empty() &&
> !event_info->is_trans_event() &&
> >>>>>> +               !stmt_has_updated_trans_table(thd))
> >>>>>> +      {
> >>>>>> +        file= &cache_mngr->stmt_cache.cache_log;
> >>>>>> +        cache_data=  &cache_mngr->stmt_cache;
> >>>>>> +      }
> >>>>>> +      else
> >>>>>> +      {
> >>>>>> +        file= &cache_mngr->trx_cache.cache_log;
> >>>>>> +        cache_data= &cache_mngr->trx_cache;
> >>>>>> +      }
> >>>>>> +   
> >>>>>> +      thd->binlog_start_trans_and_stmt();
> >>>>>>      }
> >>>>>>  
> >>>>>>     
> >>>>>>       
> >>>>>>           
> >>>>>>             
> >>>>>   
> >>>>>     
> >>>>>         
> >>>>>           
> >>>>   
> >>>>       
> >>>>         
> >>>     
> >>>       
> >>   
> >>     
> >
> >
> >   
> 
> 

Thread
bzr commit into mysql-pe branch (alfranio.correia:3512) WL#2687Alfranio Correia11 Sep
  • Re: bzr commit into mysql-pe branch (alfranio.correia:3512) WL#2687He Zhenxing13 Sep
    • Re: bzr commit into mysql-pe branch (alfranio.correia:3512) WL#2687Alfranio Correia13 Sep
      • Re: bzr commit into mysql-pe branch (alfranio.correia:3512) WL#2687Alfranio Correia13 Sep
        • Re: bzr commit into mysql-pe branch (alfranio.correia:3512) WL#2687He Zhenxing14 Sep
          • Re: bzr commit into mysql-pe branch (alfranio.correia:3512) WL#2687Alfranio Correia14 Sep
            • Re: bzr commit into mysql-pe branch (alfranio.correia:3512) WL#2687Alfranio Correia14 Sep
              • Re: bzr commit into mysql-pe branch (alfranio.correia:3512) WL#2687He Zhenxing14 Sep
              • Re: bzr commit into mysql-pe branch (alfranio.correia:3512) WL#2687Andrei Elkin14 Sep
                • Re: bzr commit into mysql-pe branch (alfranio.correia:3512) WL#2687He Zhenxing14 Sep
                  • Re: bzr commit into mysql-pe branch (alfranio.correia:3512) WL#2687Alfranio Correia14 Sep
                  • Re: bzr commit into mysql-pe branch (alfranio.correia:3512) WL#2687Andrei Elkin14 Sep
                    • Re: bzr commit into mysql-pe branch (alfranio.correia:3512) WL#2687He Zhenxing15 Sep
                      • Re: bzr commit into mysql-pe branch (alfranio.correia:3512) WL#2687Andrei Elkin15 Sep
                        • Re: bzr commit into mysql-pe branch (alfranio.correia:3512) WL#2687Alfranio Correia17 Sep
                          • Re: bzr commit into mysql-pe branch (alfranio.correia:3512) WL#2687Andrei Elkin17 Sep
                            • Re: bzr commit into mysql-pe branch (alfranio.correia:3512) WL#2687Alfranio Correia20 Sep
                              • Re: bzr commit into mysql-pe branch (alfranio.correia:3512) WL#2687Andrei Elkin22 Sep
                                • Re: bzr commit into mysql-pe branch (alfranio.correia:3512) WL#2687Alfranio Correia22 Sep
                                • Re: bzr commit into mysql-pe branch (alfranio.correia:3512) WL#2687Alfranio Correia28 Sep
                                  • Re: bzr commit into mysql-pe branch (alfranio.correia:3512) WL#2687Andrei Elkin28 Sep