1. 06 Nov, 2012 1 commit
    • Vladislav Vaintroub's avatar
      MDEV-3839 : on Solaris 10, KILLing slave thread has no effect. · 679b8dc1
      Vladislav Vaintroub authored
      The reason for the error is missing definition for SIGNAL_WITH_IO_CLOSE on this platform
      which now needs to  always be defined, as in 5.6
      
      On Solaris10 only, this preprocessor constant was not defined,  thus code that shutdowns a socket in THD::awake was not executed, and polling thread was not interrupted.
      
      Fix is to always define SIGNAL_WITH_IO_CLOSE, just like MySQL5.6 does.
      679b8dc1
  2. 05 Nov, 2012 1 commit
  3. 04 Nov, 2012 4 commits
  4. 03 Nov, 2012 2 commits
    • Sergey Petrunya's avatar
      # MDEV-3817: Wrong result with index_merge+index_merge_intersection, InnoDB... · be0be7af
      Sergey Petrunya authored
      # MDEV-3817: Wrong result with index_merge+index_merge_intersection, InnoDB table, join, AND and OR conditions
      Reconcile the fixes from:
      #
      # guilhem.bichot@oracle.com-20110805143029-ywrzuz15uzgontr0
      # Fix for BUG#12698916 - "JOIN QUERY GIVES WRONG RESULT AT 2ND EXEC. OR
      # AFTER FLUSH TABLES [-INT VS NULL]"
      #
      # guilhem.bichot@oracle.com-20111209150650-tzx3ldzxe1yfwji6
      # Fix for BUG#12912171 - ASSERTION FAILED: QUICK->HEAD->READ_SET == SAVE_READ_SET
      # and
      #
      and related fixes from: BUG#1006164, MDEV-376:
      
      Now, ROR-merged QUICK_RANGE_SELECT objects make no assumptions about the values
      of table->read_set and table->write_set.
      Each QUICK_ROR_SELECT has (and had before) its own column bitmap, but now, all 
      QUICK_ROR_SELECT's functions that care: reset(), init_ror_merged_scan(), and 
      get_next()  will set table->read_set when invoked and restore it back to what 
      it was before the call before they return.
      
      This allows to avoid the mess when somebody else modifies table->read_set for 
      some reason.
      
      
      be0be7af
    • Sergei Golubchik's avatar
      merge with 5.5 · 40e94a37
      Sergei Golubchik authored
      40e94a37
  5. 02 Nov, 2012 2 commits
  6. 31 Oct, 2012 3 commits
  7. 30 Oct, 2012 5 commits
  8. 29 Oct, 2012 6 commits
  9. 28 Oct, 2012 1 commit
  10. 27 Oct, 2012 4 commits
  11. 26 Oct, 2012 1 commit
    • unknown's avatar
      MDEV-3812 · 974abc7a
      unknown authored
      This patch undoes the removal of enum store_key_result by the previous patch for mdev-3812.
      974abc7a
  12. 25 Oct, 2012 2 commits
    • Sergei Golubchik's avatar
      correct truncation in my_vsnprintf %M format · 3f129034
      Sergei Golubchik authored
      (because of a width or a short buffer)
      3f129034
    • unknown's avatar
      MDEV-3812: Remove unneeded extra call to engine->exec() in... · 97a1c53c
      unknown authored
      MDEV-3812: Remove unneeded extra call to engine->exec() in Item_subselect::exec, remove enum store_key_result
      
      This task fixes an ineffeciency that is a remainder from MySQL 5.0/5.1. There, subqueries
      were optimized in a lazy manner, when executed for the first time. During this lazy optimization
      it may happen that the server finds a more efficient subquery engine, and substitute the current
      engine of the query being executed with the new engine. This required re-execution of the engine.
      
      MariaDB 5.3 pre-optimizes subqueries in almost all cases, and the engine is chosen in most cases,
      except when subquery materialization found that it must use partial matching. In this case, the
      current code was performing one extra re-execution although it was not needed at all. The patch
      performs the re-execution only if the engine was changed while executing.
      
      In addition the patch performs small cleanup by removing "enum store_key_result" because it is
      essentially a boolean, and the code that uses it already maps it to a boolean.
      97a1c53c
  13. 22 Oct, 2012 1 commit
    • unknown's avatar
      MDEV-571 · 76d8a43e
      unknown authored
      Adjusted test case results after the merge 10.0-base, 10.0-monty.
      The results are in sync with MySQL 5.6.7.
      76d8a43e
  14. 20 Oct, 2012 2 commits
  15. 19 Oct, 2012 2 commits
  16. 18 Oct, 2012 3 commits