1. 04 Apr, 2012 2 commits
  2. 03 Apr, 2012 4 commits
  3. 02 Apr, 2012 6 commits
  4. 30 Mar, 2012 8 commits
  5. 29 Mar, 2012 5 commits
  6. 28 Mar, 2012 3 commits
    • Michael Widenius's avatar
      Automatic merge · c404e51a
      Michael Widenius authored
      c404e51a
    • Michael Widenius's avatar
      Merge with 5.1 · fbd6b0c7
      Michael Widenius authored
      fbd6b0c7
    • Michael Widenius's avatar
      Fixed lp:944422 "mysql_upgrade destroys Maria tables?" · 0a190b6b
      Michael Widenius authored
      The issue was that check/optimize/anaylze did not zerofill the table before they started to work on it.
      Added one more element to not often used function handler::auto_repair() to allow handler to decide when to auto repair.
      
      
      mysql-test/suite/maria/r/maria-autozerofill.result:
        Test case for lp:944422
      mysql-test/suite/maria/t/maria-autozerofill.test:
        Test case for lp:944422
      sql/ha_partition.cc:
        Added argument to auto_repair()
      sql/ha_partition.h:
        Added argument to auto_repair()
      sql/handler.h:
        Added argument to auto_repair()
      sql/table.cc:
        Let auto_repair() decide which errors to trigger auto-repair
      storage/archive/ha_archive.h:
        Added argument to auto_repair()
      storage/csv/ha_tina.h:
        Added argument to auto_repair()
      storage/maria/ha_maria.cc:
        Give better error & warning messages for auto-repaired tables.
      storage/maria/ha_maria.h:
        Added argument to auto_repair()
        Always auto-repair in case of moved table.
      storage/maria/ma_open.c:
        Remove special handling of HA_ERR_OLD_FILE (this is now handled in auto_repair())
      storage/myisam/ha_myisam.h:
        Added argument to auto_repair()
      0a190b6b
  7. 27 Mar, 2012 2 commits
  8. 26 Mar, 2012 8 commits
  9. 25 Mar, 2012 1 commit
    • Sergey Petrunya's avatar
      BUG#962667: Assertion `0' failed in QUICK_INDEX_SORT_SELECT::need_sorted_output() · 85af7417
      Sergey Petrunya authored
      - The problem was that
        = we've picked a LooseScan that used full index scan (tab->type==JT_ALL) on certain index.
        = there was also a quick select (tab->quick!=NULL), that used other indexes.
        = some old code assumes that (tab->type==JT_ALL && tab->quick) -> means that the
          quick select should be used, which is not true.
      Fixed by discarding the quick select as soon as we know we're using LooseScan
      without using the quick select.
      85af7417
  10. 24 Mar, 2012 1 commit