1. 01 Oct, 2010 2 commits
  2. 30 Sep, 2010 3 commits
  3. 29 Sep, 2010 2 commits
  4. 28 Sep, 2010 3 commits
  5. 27 Sep, 2010 1 commit
  6. 24 Sep, 2010 9 commits
  7. 22 Sep, 2010 3 commits
  8. 21 Sep, 2010 4 commits
  9. 20 Sep, 2010 5 commits
  10. 19 Sep, 2010 1 commit
  11. 17 Sep, 2010 3 commits
  12. 16 Sep, 2010 4 commits
    • Sergey Glukhov's avatar
      5.1-bugteam->5.5-merge · dcad3feb
      Sergey Glukhov authored
      dcad3feb
    • Sergey Glukhov's avatar
      Bug#50402 Optimizer producing wrong results when using Index Merge on InnoDB · 86d7cbd4
      Sergey Glukhov authored
      Subselect executes twice, at JOIN::optimize stage
      and at JOIN::execute stage. At optimize stage
      Innodb prebuilt struct which is used for the
      retrieval of column values is initialized in.
      ha_innobase::index_read(), prebuilt->sql_stat_start is true.
      After QUICK_ROR_INTERSECT_SELECT finished his job it
      restores read_set/write_set bitmaps with initial values
      and deactivates one of the handlers used by
      QUICK_ROR_INTERSECT_SELECT in JOIN::cleanup
      (it's the case when we reuse original handler as one of
       handlers required by QUICK_ROR_INTERSECT_SELECT object).
      On second subselect execution inactive handler is activated
      in  QUICK_RANGE_SELECT::reset, file->ha_index_init().
      In ha_index_init Innodb prebuilt struct is reinitialized
      with inappropriate read_set/write_set bitmaps. Further
      reinitialization in ha_innobase::index_read() does not
      happen as prebuilt->sql_stat_start is false.
      It leads to partial retrieval of required field values
      and we get a mix of field values from different records
      in the record buffer.
      The fix is to reset
      read_set/write_set bitmaps as these values
      are required for proper intialization of
      internal InnoDB struct which is used for
      the retrieval of column values
      (see build_template(), ha_innodb.cc)
      86d7cbd4
    • Magne Mahre's avatar
      Merge from 5.1-bugteam · 327eb7b6
      Magne Mahre authored
      327eb7b6
    • Magne Mahre's avatar
      Bug #54606 innodb fast alter table + pack_keys=0 prevents · f43d6c2b
      Magne Mahre authored
                 adding new indexes
      
      A fast alter table requires that the existing (old) table
      and indices are unchanged (i.e only new indices can be
      added).  To verify this, the layout and flags of the old
      table/indices are compared for equality with the new.
      
      The PACK_KEYS option is a no-op in InnoDB, but the flag
      exists, and is used in the table compare.  We need to
      check this (table) option flag before deciding whether an 
      index should be packed or not.  If the table has
      explicitly set PACK_KEYS to 0, the created indices should
      not be marked as packed/packable. 
      f43d6c2b