1. 14 Feb, 2013 3 commits
    • Mattias Jonsson's avatar
      Bug#16274455: CAN NOT ACESS PARTITIONED TABLES WHEN · e9618282
      Mattias Jonsson authored
      DOWNGRADED FROM 5.6.11 TO 5.6.10
      
      Problem was new syntax not accepted by previous version.
      
      Fixed by adding version comment of /*!50531 around the
      new syntax.
      
      Like this in the .frm file:
      'PARTITION BY KEY /*!50611 ALGORITHM = 2 */ () PARTITIONS 3'
      and also changing the output from SHOW CREATE TABLE to:
      CREATE TABLE t1 (a INT)
      /*!50100 PARTITION BY KEY */ /*!50611 ALGORITHM = 1 */ /*!50100 ()
      PARTITIONS 3 */
      
      It will always add the ALGORITHM into the .frm for KEY [sub]partitioned
      tables, but for SHOW CREATE TABLE it will only add it in case it is the non
      default ALGORITHM = 1.
      
      Also notice that for 5.5, it will say /*!50531 instead of /*!50611, which
      will make upgrade from 5.5 > 5.5.31 to 5.6 < 5.6.11 fail!
      If one downgrades an fixed version to the same major version (5.5 or 5.6) the
      bug 14521864 will be visible again, but unless the .frm is updated, it will
      work again when upgrading again.
      
      Also fixed so that the .frm does not get updated version
      if a single partition check passes.
      e9618282
    • Annamalai Gurusami's avatar
      Merge from mysql-5.1 to mysql-5.5 · 84ef8470
      Annamalai Gurusami authored
      84ef8470
    • Annamalai Gurusami's avatar
      For the error code ER_TOO_LONG_IDENT, the identifier is expected in the... · 5d47242d
      Annamalai Gurusami authored
      For the error code ER_TOO_LONG_IDENT, the identifier is expected in the my_error call.  So removing this line from here.  
      5d47242d
  2. 12 Feb, 2013 2 commits
  3. 08 Feb, 2013 4 commits
  4. 07 Feb, 2013 3 commits
  5. 06 Feb, 2013 1 commit
  6. 05 Feb, 2013 2 commits
  7. 04 Feb, 2013 2 commits
  8. 08 Feb, 2013 3 commits
  9. 07 Feb, 2013 3 commits
  10. 06 Feb, 2013 3 commits
    • unknown's avatar
      Bug#16263506 - INNODB; USE ABORT() ON ALL PLATFORMS INSTEAD OF · 6f83811d
      unknown authored
                     DEREFERENCING UT_DBG_NULL_PTR
      The abort() call is standard C but InnoDB only uses it in GCC
      environments.  UT_DBG_USE_ABORT is not defined the code crashed
      by dereferencing a null pointer instead of calling abort().
      Other code throughout MySQL including ndb, sql, mysys and other
      places call abort() directly.
      
      This bug also affects innodb.innodb_bug14147491.test which fails
      randomly on windows because of this issue. 
      
      Approved by marko in http://rb.no.oracle.com/rb/r/1936/
      6f83811d
    • Ravinder Thakur's avatar
      Bug#14711808 MSI INSTALLATION / UPGRADE CAN CORRUPT EXISTING INSTALLATION · 6823ac91
      Ravinder Thakur authored
      Currently MySQL MSI installer on Windows installs MySQL in 
      "per user" mode. It means that if a Windows machine has 
      multiple users, they each can install MySQL independently. 
      However the default path of MySQL is "C:\Program Files (x86)\MySQL\"
      and when two users install MySQL on same machine, the installation
      by second user just overwrites the MySQL files. This default shared 
      location leads to the issue where if the second user uninstalls MySQL,
      the installation files are removed for the first user as well.
      
      In this fix, we are now making the default installation "per machine".
      It means that when MySQL is installed with defaults options, all
      users can see the shortcuts for MySQL in start menu(since installations 
      is for all users). Also when any user relaunches the installer, it will 
      consider that action uninstallation rather than installation for that user.
      
      There are command line options in installer that can be used to undo the
      "per machine" installation but will not consider that scenario.MySQL 
      is a server product and it does not make a lot of sense to install it
      differently for each user.
      6823ac91
    • unknown's avatar
      13625278 5.1 => 5.5 · 5948623e
      unknown authored
      5948623e
  11. 05 Feb, 2013 4 commits
    • Hery Ramilison's avatar
      Upmerge of the 5.1.68 build · 67a697b7
      Hery Ramilison authored
      67a697b7
    • unknown's avatar
      Merge from mysql-5.5.30-release · a6a20c11
      unknown authored
      a6a20c11
    • unknown's avatar
      13625278 5.1=> 5.5 · c8738c1f
      unknown authored
      c8738c1f
    • Thayumanavar's avatar
      BUG#16196591 - CLIENTS CANNOT CONNECT TO MYSQL · e15a5136
      Thayumanavar authored
      PROBLEM:
      When large number of connections are continuously made
      with wait_timeout of 600 seconds for  some hours, some
      connections remain after wait_timeout expired and also
      new connections get struck under the configuration and
      the scenario reported in bug#16196591.
      FIX:
      The cause of this bug is the issue identified  and fixed in
      the BUG#16088658 in 5.6.Also LOCK_thread_count contention 
      issue fixed in BUG#15921866 in 5.6 need to be in 5.5 as 
      well. Since the issue is not reproducible, it has been
      verified at customer configuration the issue could not
      be reproduced after a 48-hour test with a non-debug build               
      which includes the above two fixes backported.
      e15a5136
  12. 04 Feb, 2013 1 commit
  13. 01 Feb, 2013 3 commits
  14. 31 Jan, 2013 6 commits
    • Gleb Shchepa's avatar
      Bug #11827369: ASSERTION FAILED: !THD->LEX->CONTEXT_ANALYSIS_ONLY · dff10afb
      Gleb Shchepa authored
      Manual up-merge from 5.1 to 5.5.
      dff10afb
    • Gleb Shchepa's avatar
      Bug #11827369: ASSERTION FAILED: !THD->LEX->CONTEXT_ANALYSIS_ONLY · 7ebfe30b
      Gleb Shchepa authored
      Some queries with the "SELECT ... FROM DUAL" nested subqueries
      failed with an assertion on debug builds.
      Non-debug builds were not affected.
      
      There were a few different issues with similar assertion
      failures on different queries:
      
      1. The first problem was related to the incomplete propagation
      of the "non-constant" item status from underlying subquery
      items to the outer item tree: in some cases non-constants were
      interpreted as constants and evaluated at the preparation stage
      (val_int() calls withing fix_fields() etc).
      
      Thus, the default implementation of Item_ref::const_item() from
      the Item parent class didn't take into account the "const_item"
      status of the referenced item tree -- it used the insufficient
      "used_tables() == 0" check instead. This worked in most cases
      since our "non-constant" functions like RAND() and SLEEP() set
      the RAND_TABLE_BIT in the used table map, so they aren't
      non-constant from Item_ref's "point of view". However, the
      "SELECT ... FROM DUAL" subquery may have an empty map of used
      tables, but at the same time subqueries are never "constant" at
      the context analysis stage (preparation, view creation etc).
      So, the non-contantness of such subqueries was missed.
      
      Fix: the Item_ref::const_item() function has been overloaded to
      take into account both (*ref)->const_item() status and tricky
      Item_ref::used_tables() return values, since the only
      (*ref)->const_item() call is not enough there.
      
      2. In some cases instead of the const_item() call we check a
      value of the Item::with_subselect field to recognize items
      with nested subqueries. However, the Item_ref class didn't
      propagate this value from the referenced item tree.
      
      Fix: Item::has_subquery() and Item_ref::has_subquery()
      functions have been backported from 5.6. All direct
      references to the with_subselect fields of nested items have
      been replaced with the has_subquery() function call.
      
      3. The Item_func_regex class didn't propagate with_subselect
      as well, since it overloads the Item_func::fix_fields()
      function with insufficient fix_fields() implementation.
      
      Fix: the Item_func_regex::fix_fields() function has been
      modified to gather "constant" statuses from inner items.
      
      4. The Item_func_isnull::update_used_tables() function has
      a special branch for the underlying item where the maybe_null
      value is false: in this case it marks the Item_func_isnull
      as a "const_item" and sets the cached_value to false.
      However, the Item_func_isnull::val_int() was not in sync with
      update_used_tables(): it didn't take into account neither
      const_item_cache nor cached_value for the case of
      "args[0]->maybe_null == false optimization".
      As far as such an Item_func_isnull has "const_item() == true",
      it's ok to call Item_func_isnull::val_int() etc from outer
      items on preparation stage. In this case the server tried to
      call Item_func_isnull::args[0]->isnull(), and if the args[0]
      item contained a nested not-nullable subquery, it failed
      with an assertion.
      
      Fix: take the value of Item_func_isnull::const_item_cache into
      account in the val_int() function.
      
      5. The auxiliary Item_is_not_null_test class has a similar
      optimization in the update_used_tables() function as the
      Item_func_isnull class has, and the same issue in the val_int()
      function.
      In addition to that the Item_is_not_null_test::update_used_tables()
      doesn't update the const_item_cache value, so the "maybe_null"
      optimization is useless there. Thus, we missed some optimizations
      of cases like these (before and after the fix):
        <  <is_not_null_test>(a),
        ---
        >  <cache>(<is_not_null_test>(a)),
      or
        < having (<is_not_null_test>(a) and <is_not_null_test>(a))
        ---
        > having 1
      etc.
      
      Fix: update Item_is_not_null_test::const_item_cache in
      update_used_tables() and take in into account in val_int().
      7ebfe30b
    • Yasufumi Kinoshita's avatar
      merge to mysql-5.5 from mysql-5.1 · 4dcd0304
      Yasufumi Kinoshita authored
      4dcd0304
    • Yasufumi Kinoshita's avatar
      Bug #16220051 : INNODB_BUG12400341 FAILS ON VALGRIND WITH TOO MANY ACTIVE CONCURRENT TRANSACTION · c3d2803c
      Yasufumi Kinoshita authored
      innodb_bug12400341.test is disabled for valgrind daily test.
      It might be affected by the previous test's undo slots existing,
      because of slower execution.
      c3d2803c
    • Chaithra Gopalareddy's avatar
      Bug#14096619: UNABLE TO RESTORE DATABASE DUMP · dbd25312
      Chaithra Gopalareddy authored
      Backport of fix for Bug#13581962
      
      mysql-test/r/cast.result:
        Added test result for Bug#13581962,Bug#14096619
      mysql-test/r/ctype_utf8mb4.result:
        Added test result for Bug#13581962,Bug#14096619
      mysql-test/t/cast.test:
        Added test case for Bug#13581962,Bug#14096619
      mysql-test/t/ctype_utf8mb4.test:
        Added test case for Bug#13581962,Bug#14096619
      sql/item_func.h:
        limit max length by MY_INT64_NUM_DECIMAL_DIGITS
      dbd25312
    • Chaithra Gopalareddy's avatar
      Bug#14096619: UNABLE TO RESTORE DATABASE DUMP · e1ee9581
      Chaithra Gopalareddy authored
      Backport of Bug#13581962
      
      mysql-test/r/cast.result:
        Added test result for Bug#13581962,Bug#14096619
      mysql-test/t/cast.test:
        Added test case for Bug#13581962,Bug#14096619
      sql/item_func.h:
        limit max length by MY_INT64_NUM_DECIMAL_DIGITS
      e1ee9581