1. 18 Aug, 2011 1 commit
    • Sergey Vojtovich's avatar
      BUG#11763712 - 56458: KILLING A FLUSH TABLE FOR A MERGE/CHILD · 06fa1ef4
      Sergey Vojtovich authored
                            CRASHES SERVER
      
      Flushing of MERGE table or one of its child tables, which was
      locked by flushing thread using LOCK TABLES, might have caused
      crashes or assertion failures if the thread failed to reopen
      child or parent table.
      Particularly, this might have happened when another connection
      killed this FLUSH TABLE statement/connection.
      Also this problem might have occurred when we failed to reopen
      MERGE table or one of its children when executing DDL statement
      under LOCK TABLES.
      
      The problem was caused by the fact that reopen_tables() might
      have failed to reopen child table but still tried to reopen,
      reattach children for and re-lock its parent. Vice versa it
      might have failed to reopen parent but kept references from
      children to parent around. Since reopen_tables() closes table
      it has failed to reopen and therefore frees all associated
      memory such dangling references led to crashes when followed.
      
      This patch solves this problem by ensuring that we always close
      parent table and all its children if we fail to reopen this
      table or one of its children. Same happens if we fail to reattach
      children to parent.
      
      Affects 5.1 only.
      06fa1ef4
  2. 04 May, 2011 1 commit
    • Alexander Nozdrin's avatar
      Patch for Bug#12394306: the sever may crash if mysql.event is corrupted. · ca6e7781
      Alexander Nozdrin authored
      The problem was that wrong structure of mysql.event was not detected and
      the server continued to use wrongly-structured data.
      
      The fix is to check the structure of mysql.event after opening before
      any use. That makes operations with events more strict -- some operations
      that might work before throw errors now. That seems to be Ok.
      
      Another side-effect of the patch is that if mysql.event is corrupted,
      unrelated DROP DATABASE statements issue an SQL warning about inability
      to open mysql.event table. 
      ca6e7781
  3. 03 May, 2011 1 commit
  4. 02 May, 2011 1 commit
  5. 29 Apr, 2011 5 commits
  6. 27 Apr, 2011 3 commits
  7. 26 Apr, 2011 3 commits
  8. 25 Apr, 2011 1 commit
  9. 23 Apr, 2011 1 commit
  10. 22 Apr, 2011 1 commit
    • Sergey Glukhov's avatar
      Bug#11756928 48916: SERVER INCORRECTLY PROCESSING HAVING CLAUSES WITH AN ORDER BY CLAUSE · 76f37a02
      Sergey Glukhov authored
      Before sorting HAVING condition is split into two parts,
      first part is a table related condition and the rest of is
      HAVING part. Extraction of HAVING part does not take into account
      the fact that some of conditions might be non-const but
      have 'used_tables' == 0 (independent subqueries)
      and because of that these conditions are cut off by
      make_cond_for_table() function.
      The fix is to use (table_map) 0 instead of used_tables in
      third argument for make_cond_for_table() function.
      It allows to extract elements which belong to sorted
      table and in addition elements which are independend
      subqueries.
      76f37a02
  11. 21 Apr, 2011 1 commit
  12. 20 Apr, 2011 6 commits
  13. 18 Apr, 2011 4 commits
  14. 16 Apr, 2011 1 commit
  15. 15 Apr, 2011 3 commits
  16. 14 Apr, 2011 4 commits
  17. 13 Apr, 2011 1 commit
  18. 12 Apr, 2011 2 commits