1. 18 Jun, 2012 1 commit
    • unknown's avatar
      MDEV-346: 5.5 upgrade test fails on precise. · 11f72340
      unknown authored
      Attempt to make it easier to upgrade mysql->mariadb on Ubuntu precise.
      It looks like we were missing conflicts: and replaces: on packages
      mysql-server-5.5 and mysql-client-5.5.
      11f72340
  2. 17 Jun, 2012 1 commit
  3. 16 Jun, 2012 2 commits
  4. 15 Jun, 2012 11 commits
  5. 14 Jun, 2012 1 commit
  6. 13 Jun, 2012 2 commits
  7. 10 Jun, 2012 3 commits
  8. 09 Jun, 2012 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #1010729. · 10f42e2c
      Igor Babaev authored
      The bug prevented acceptance of UNION queries whose non-first select 
      clauses contained join expressions with degenerated single-table nests
      as valid queries.
      The bug was introduced into mysql-5.5 code line by the patch for
      bug 33204.
      10f42e2c
  9. 08 Jun, 2012 5 commits
    • Michael Widenius's avatar
    • Michael Widenius's avatar
      Changed last_insert_id() to be unsigned. · 438e9eca
      Michael Widenius authored
      Fixed MDEV-331: last_insert_id() returns a signed number
      
      mysql-test/r/auto_increment.result:
        Added test case
      mysql-test/t/auto_increment.test:
        Added test case
      sql/item_func.h:
        Changed last_insert_id() to be unsigned.
      438e9eca
    • Vladislav Vaintroub's avatar
      LP1008334 : Speedup specific datetime queries that got slower with... · afe1ef5e
      Vladislav Vaintroub authored
      LP1008334 : Speedup specific datetime queries that got slower with introduction of microseconds in 5.3
      
      - Item::get_seconds() now skips decimal arithmetic, if decimals is 0. This significantly speeds up from_unixtime() if no fractional part is passed.
      - replace sprintfs used to format temporal values  by hand-coded formatting 
        
      Query1 (original query in the bug report)
      BENCHMARK(10000000,DATE_SUB(FROM_UNIXTIME(RAND() * 2147483648), INTERVAL (FLOOR(1 + RAND() * 365)) DAY)) 
        
      Query2 (Variation of query1 that does not use fractional part in FROM_UNIXTIME parameter)
      BENCHMARK(10000000,DATE_SUB(FROM_UNIXTIME(FLOOR(RAND() * 2147483648)), INTERVAL (FLOOR(1 + RAND() * 365)) DAY)) 
        
      Prior to the patch, the runtimes were (32 bit compilation/AMD machine)
      Query1: 41.53 sec 
      Query2: 23.90 sec
        
      With the patch, the runtimes are
      Query1: 32.32 sec (speed up due to removing sprintf)
      Query2: 12.06 sec (speed up due to skipping decimal arithmetic)
      afe1ef5e
    • Sergei Golubchik's avatar
      apply mysql fix for bug#58421 to XtraDB · d2ca6d2e
      Sergei Golubchik authored
      d2ca6d2e
    • unknown's avatar
      MDEV-329: MariaDB 5.5 does not use fdatasync(). · cb6109cd
      unknown authored
      The --debug-no-sync incorrectly defaulted to ON, disabling sync calls
      by default which can loose data or cause corruption. Also, the code
      used fsync() instead of the sometimes more efficient fdatasync().
      cb6109cd
  10. 07 Jun, 2012 1 commit
  11. 06 Jun, 2012 5 commits
  12. 05 Jun, 2012 1 commit
    • unknown's avatar
      Fixed bug lp:1000649 · f1ab0089
      unknown authored
      Analysis:
      
      When the method JOIN::choose_subquery_plan() decided to apply
      the IN-TO-EXISTS strategy, it set the unit and select_lex
      uncacheable flag to UNCACHEABLE_DEPENDENT_INJECTED unconditionally.
      As result, even if IN-TO-EXISTS injected non-correlated predicates,
      the subquery was still treated as correlated.
      
      Solution:
      Set the subquery as correlated only if the injected predicate(s) depend
      on the outer query.
      f1ab0089
  13. 04 Jun, 2012 4 commits
    • Sergei Golubchik's avatar
      MDEV-308 lp:1008516 - Failing assertion: templ->mysql_col_len == len · 265d5aaa
      Sergei Golubchik authored
      remove the offending assert.
      take the test case from mysql Bug#58015
      265d5aaa
    • Sergei Golubchik's avatar
      MDEV-136 Non-blocking "set read_only" · 4361c864
      Sergei Golubchik authored
      backport dmitry.shulga@oracle.com-20120209125742-w7hdxv0103ymb8ko from mysql-trunk:
      
        Patch for bug#11764747 (formerly known as 57612): SET GLOBAL READ_ONLY=1 cannot
        progress when a table is locked with LOCK TABLES.
        
        The reason for the bug was that mysql server makes a flush of all open tables
        during handling of statement 'SET GLOBAL READ_ONLY=1'. Therefore if some of
        these tables were locked by "LOCK TABLE ... READ" from a different connection,
        then execution of statement 'SET GLOBAL READ_ONLY=1' would be waiting for
        the lock for such table even if the table was locked in a compatible read mode.
        
        Flushing of all open tables before setting of read_only system variable
        is inherited from 5.1 implementation since this was the only possible approach
        to ensure that there isn't any pending write operations on open tables.
        
        Start from version 5.5 and above such behaviour is guaranteed by the fact
        that we acquire global_read_lock before setting read_only flag. Since
        acquiring of global_read_lock is successful only when there isn't any 
        active write operation then we can remove flushing of open tables from
        processing of SET GLOBAL READ_ONLY=1.
        
        This modification changes the server behavior so that read locks held
        by other connections (LOCK TABLE ... READ) no longer will block attempts
        to enable read_only.
      4361c864
    • Sergei Golubchik's avatar
      merge with 5.3. · 3e3606d2
      Sergei Golubchik authored
      Take only test cases from MDEV-136 Non-blocking "set read_only"
      3e3606d2
    • unknown's avatar
      Fix bug lp:1008487 · ca5473f1
      unknown authored
      Analysis:
      The crash is a result of Item_cache_temporal::example not being set
      (it is NULL). It turns out that the value of Item_cache_temporal
      may be set directly by calling Item_cache_temporal::store_packed
      without ever setting the "example" of this Item_cache. Therefore
      the failing assertion is too narrow.
      
      Solution:
      Remove the assert.
      In principle we could overwrite this method for Item_cache_temporal,
      but it doesn't make sense just for this assert.
      ca5473f1
  14. 02 Jun, 2012 1 commit
  15. 01 Jun, 2012 1 commit