1. 22 Feb, 2010 2 commits
    • Luis Soares's avatar
      d9da9010
    • Luis Soares's avatar
      Post-push fix for BUG#50364. · 1e638e72
      Luis Soares authored
      There was an erroneous parameter when calling flush_master_info
      from write_ignored_events_info_to_relay_log which could lead to a
      server crash. This happens because the I/O thread releases the
      log_lock before calling the flush_master_info.
      
      Set the function to call flush_master_info with third parameter
      to true, so that the mutex is properly taken.
      1e638e72
  2. 21 Feb, 2010 1 commit
  3. 20 Feb, 2010 9 commits
  4. 19 Feb, 2010 2 commits
  5. 18 Feb, 2010 4 commits
  6. 17 Feb, 2010 14 commits
  7. 16 Feb, 2010 7 commits
  8. 15 Feb, 2010 1 commit
    • Konstantin Osipov's avatar
      A fix and a test case for Bug#47648 "main.merge fails sporadically". · dd510064
      Konstantin Osipov authored
      If a prepared statement used both a MyISAMMRG table and a stored 
      function or trigger, execution could fail with "No such table"
      error or crash. 
      The error would come from a failure of the MyISAMMRG engine
      to meet the expectations of the prelocking algorithm, 
      in particular maintain lex->query_tables_own_last pointer
      in sync with lex->query_tables_last pointer/the contents
      of lex->query_tables. When adding merge children, the merge
      engine would extend the table list. Then, when adding 
      prelocked tables, the prelocking algorithm would use a pointer
      to the last merge child to assign to lex->query_tables_own_last.
      Then, when merge children were removed at the end of
      open_tables(), lex->query_tables_own_last
      was not updated, and kept pointing
      to a removed merge child.
      
      The fix ensures that query_tables_own_last is always in
      sync with lex->query_tables_last.
      
      This is a regression introduced by WL#4144 and present only
      in next-4284 tree and 6.0.
      dd510064