1. 21 Oct, 2011 3 commits
  2. 20 Oct, 2011 1 commit
    • Sergey Vojtovich's avatar
      BUG#11757032 - 49030: OPTIMIZE TABLE BREAKS MYISAM TABLE WHEN · 2c1bcb80
      Sergey Vojtovich authored
                     USING MYISAM_USE_MMAP ON WINDOWS
      
      When OPTIMIZE/REPAIR TABLE is switching to new data file,
      old data file is removed while memory mapping is still
      active.
      
      With 5.1 implementation of nt_share_delete() it is not
      permitted to remove mmaped file.
      
      This fix disables memory mapping for mi_repair() operations.
      
      mysql-test/r/myisam.result:
        A test case for BUG#11757032.
      mysql-test/t/myisam.test:
        A test case for BUG#11757032.
      storage/myisam/ha_myisam.cc:
        mi_repair*() functions family use file I/O even if memory
        mapping is available.
        
        Since mixing mmap I/O and file I/O may cause various artifacts,
        memory mapping must be disabled.
      storage/myisam/mi_delete_all.c:
        Clean-up: do not attempt to remap file after truncate, since
        there is nothing to map.
      2c1bcb80
  3. 19 Oct, 2011 1 commit
  4. 18 Oct, 2011 1 commit
  5. 13 Oct, 2011 1 commit
  6. 12 Oct, 2011 2 commits
    • Marko Mäkelä's avatar
      Bug#13006367 62487: innodb takes 3 minutes to clean up the adaptive · 6d47a353
      Marko Mäkelä authored
      hash index at shutdown
      
      btr_search_disable(): Just drop the entire adaptive hash index,
      without dropping every record separately.
      
      buf_pool_clear_hash_index(): Renamed and simplified from
      buf_pool_drop_hash_index(). Set block->index = NULL for every block in
      the buffer pool. Do not release the btr_search_latch. The caller will
      have to adjust other data structures.
      
      Remove block->is_hashed. It is redundant, should be always equal to
      block->index != NULL.
      
      Remove btr_search_fully_disabled, btr_search_enabled_mutex, and
      SYNC_SEARCH_SYS_CONF. We drop the AHI in one pass, without releasing
      the btr_search_latch in between.
      
      Replace void* with const rec_t* and add assertions on btr_search_latch
      and btr_search_enabled to ha0ha.h, ha0ha.ic, ha0ha.c.
      
      page_set_max_trx_id(): Ignore the adaptive hash index. I forgot to
      push this in rb:750.
      
      btr0sea.c: Always after acquiring btr_search_latch, check for
      block->index==NULL or !btr_search_enabled. We can now set
      block->index=NULL while only holding btr_search_latch in exclusive
      mode. Always acquire btr_search_latch before reading block->index,
      except in shortcuts when testing for block->index == NULL.
      
      ha_clear(), ha_search(): Unused function, remove.
      
      buf_page_peek_if_search_hashed(): Remove. This function may avoid
      latching a page at the cost of doing a duplicate buf_pool->page_hash
      lookup.
      
      rb:775 approved by Inaam Rana
      6d47a353
    • Vinay Fisrekar's avatar
      bug#11766457 - adjusting/modifying the the tests as tests were failing if... · da604543
      Vinay Fisrekar authored
      bug#11766457 - adjusting/modifying the the tests as tests were failing if system time zone is set differently.
      da604543
  7. 05 Oct, 2011 4 commits
    • Bjorn Munch's avatar
      merge 5.1-mtr => 5.1 · 41200717
      Bjorn Munch authored
      41200717
    • Sergey Glukhov's avatar
      automerge · a9f38855
      Sergey Glukhov authored
      a9f38855
    • Sergey Glukhov's avatar
      Bug#11747970 34660: CRASH WHEN FEDERATED TABLE LOSES CONNECTION DURING INSERT ... SELECT · 06b86f15
      Sergey Glukhov authored
      Problematic query:
      insert ignore into `t1_federated` (`c1`) select `c1` from  `t1_local` a
      where not exists (select 1 from `t1_federated` b where a.c1 = b.c1);
      When this query is killed in another connection it could lead to crash.
      The problem is follwing:
      An attempt to obtain table statistics for subselect table in killed query
      fails with an error. So JOIN::optimize() for subquery is failed but
      it does not prevent further subquery evaluation.
      At the first subquery execution JOIN::optimize() is called
      (see subselect_single_select_engine::exec()) and fails with
      an error. 'executed' flag is set to TRUE and it prevents
      further subquery evaluation. At the second call
      JOIN::optimize() does not happen as 'JOIN::optimized' is TRUE
      and in case of uncacheable subquery the 'executed' flag is set
      to FALSE before subquery evaluation. So we loose 'optimize stage'
      error indication (see subselect_single_select_engine::exec()).
      In other words 'executed' flag is used for two purposes, for
      error indication at JOIN::optimize() stage and for an
      indication of subquery execution. And it seems it's wrong
      as the flag could be reset.
      
      
      mysql-test/r/error_simulation.result:
        test case
      mysql-test/t/error_simulation.test:
        test case
      sql/item_subselect.cc:
        added new flag subselect_single_select_engine::optimize_error
        which is used for error detection which could happen at optimize
        stage.
      sql/item_subselect.h:
        added new flag subselect_single_select_engine::optimize_error
      sql/sql_select.cc:
        test case
      06b86f15
    • Marko Mäkelä's avatar
      Add InnoDB UNIV_SYNC_DEBUG assertions to rw-lock code. · 4b66540e
      Marko Mäkelä authored
      rw_lock_x_lock_func(): Assert that the thread is not already holding
      the lock in a conflicting mode (RW_LOCK_SHARED).
      
      rw_lock_s_lock_func(): Assert that the thread is not already holding
      the lock in a conflicting mode (RW_LOCK_EX).
      4b66540e
  8. 04 Oct, 2011 5 commits
  9. 03 Oct, 2011 1 commit
  10. 28 Sep, 2011 1 commit
    • Raghav Kapoor's avatar
      BUG#11758062 - 50206: ER_TOO_BIG_SELECT REFERS TO OUTMODED · ac09b9e0
      Raghav Kapoor authored
      SYSTEM VARIABLE NAME SQL_MAX_JOIN_SI 
      
      BACKGROUND:
      
      ER_TOO_BIG_SELECT refers to SQL_MAX_JOIN_SIZE, which is the
      old name for MAX_JOIN_SIZE.
      
      FIX:
      
      Support for old name SQL_MAX_JOIN_SIZE is removed in MySQL 5.6
      and is renamed as MAX_JOIN_SIZE.So the errmsg.txt 
      and mysql.cc files have been updated and the corresponding result
      files have also been updated.
      ac09b9e0
  11. 27 Sep, 2011 2 commits
  12. 26 Sep, 2011 2 commits
  13. 22 Sep, 2011 1 commit
  14. 21 Sep, 2011 1 commit
    • unknown's avatar
      Bug 12963823 - Crash in Purge thread under unusual circumstances. · 0b8242cd
      unknown authored
      The problem occurred when indexes are added between the time that an
      UNDO record is created and the time that the purge thread comes around
      and deletes the old secondary index entries.  The purge thread would
      hit an assert when trying to build a secondary index entry for
      searching.  The problem was that the old value of those fields were not
      in the UNDO record since they were not part of an index when the UPDATE
      occured. 
      A test case was added to innodb-index.test.
      0b8242cd
  15. 20 Sep, 2011 1 commit
  16. 19 Sep, 2011 1 commit
  17. 16 Sep, 2011 2 commits
    • Sergey Vojtovich's avatar
      Merge. · f3c21f58
      Sergey Vojtovich authored
      f3c21f58
    • Sergey Vojtovich's avatar
      BUG#11761180 - 53646: MYISAMPACK CORRUPTS TABLES WITH · 0c606aac
      Sergey Vojtovich authored
                     FULLTEXT INDEXES
      
      myisamchk may create incorrect fulltext index for compressed
      tables. Incorrect data pointer size was used while creating
      fulltext index.
      
      mysql-test/r/myisampack.result:
        A test case for BUG#11761180.
      mysql-test/t/myisampack.test:
        A test case for BUG#11761180.
      storage/myisam/ft_boolean_search.c:
        rec_reflength on share may have adjustments required for
        compressed tables and must be used instead of rec_reflength
        on base info.
      storage/myisam/ft_nlq_search.c:
        rec_reflength on share may have adjustments required for
        compressed tables and must be used instead of rec_reflength
        on base info.
      storage/myisam/mi_check.c:
        rec_reflength on share may have adjustments required for
        compressed tables and must be used instead of rec_reflength
        on base info.
      storage/myisam/mi_write.c:
        rec_reflength on share may have adjustments required for
        compressed tables and must be used instead of rec_reflength
        on base info.
      0c606aac
  18. 15 Sep, 2011 2 commits
  19. 14 Sep, 2011 3 commits
  20. 13 Sep, 2011 2 commits
  21. 12 Sep, 2011 1 commit
    • Marko Mäkelä's avatar
      Bug#12601439 CONSISTENT READ FAILURE IN COLUMN PREFIX INDEX · ae68af40
      Marko Mäkelä authored
      When there is a secondary index on a column prefix of an externally
      stored column and an entry in the secondary index is shorter than the
      reserved prefix length, it should mean that the secondary index entry
      is holding the complete column value. When comparing this secondary
      index column value to the column in the clustered index row, we must
      compare the entire prefix that was fetched from the clustered
      index. The bug was that we would just compare that the column in the
      clustered index starts with the value found in the secondary index
      column.
      
      This bug affects only the InnoDB Barracuda formats (ROW_FORMAT=DYNAMIC
      and ROW_FORMAT=COMPRESSED), in which columns that are stored off-page
      in the clustered index do not contain any prefix in the clustered
      index record.
      
      row_sel_sec_rec_is_for_blob(): Add the parameter prefix_len, for
      ifield->prefix_len. Add some assertions.
      
      Sorry, I did not manage to produce a test case. This patch does
      produce correct results on the data set that Michael isolated on our
      test machine. That was with the purge and background rollback
      suspended, because they would make the bug go away.
      
      rb:760 approved by Sunny Bains
      ae68af40
  22. 09 Sep, 2011 1 commit
  23. 08 Sep, 2011 1 commit
    • Marko Mäkelä's avatar
      Bug#12948130 UNNECESSARY X-LOCKING OF ADAPTIVE HASH INDEX (BTR_SEARCH_LATCH) · a6aa010e
      Marko Mäkelä authored
      InnoDB acquires an x-latch on btr_search_latch for certain in-place updates
      that do affect the adaptive hash index. These operations do not really need
      to be protected by the btr_search_latch:
      
      * updating DB_TRX_ID
      * updating DB_ROLL_PTR
      * updating PAGE_MAX_TRX_ID
      * updating the delete-mark flag
      
      rb:750 approved by Sunny Bains
      a6aa010e