1. 06 Mar, 2013 2 commits
  2. 05 Mar, 2013 2 commits
  3. 01 Mar, 2013 3 commits
    • unknown's avatar
      Updated mysql.spec.sh file for br16298542 · 4b03a184
      unknown authored
      4b03a184
    • Marc Alff's avatar
      L0ocal merge · 834c55fb
      Marc Alff authored
      834c55fb
    • Venkatesh Duggirala's avatar
      BUG#11753923-SQL THREAD CRASHES ON DISK FULL · 8b2efea8
      Venkatesh Duggirala authored
      Fixing post push issue
      Simulator name used needs to be changed to make it
      work properly.
      
      Analysis: 
      Debug control list addition (ListAddDel function
      dbug.c file) code was written in such a way that
      if new element is subset of already existing element,
      then the new element is not added.
      i.e., set @@global.debug = '+d,abcd', is existing in
      the list then you cannot add "a" or "ab" or "abc"
      in the list.
      8b2efea8
  4. 28 Feb, 2013 7 commits
    • Jon Olav Hauglid's avatar
      Bug#16385711: HANDLER, CREATE TABLE IF NOT EXISTS, · 65163f8c
      Jon Olav Hauglid authored
                    PROBLEM AFTER MYSQL_HA_FIND
      
      This problem occured if a prepared statement tried to create a table
      for which there already existed a view with the same name while a
      SQL handler was opened.
      
      Before DDL statements are executed, mysql_ha_rm_tables() is called
      to remove any matching tables from the internal list of opened SQL
      handler tables. This match was done on TABLE_LIST::db and 
      TABLE_LIST::table_name. This is problematic for views (which use
      TABLE_LIST::view_db and TABLE_LIST::view_name) and anonymous
      derived tables.
      
      This patch fixes the problem by skipping TABLE_LISTs representing
      anonymous derived tables and using get_db_name()/get_table_name()
      which handles views when looking for SQL handler tables to remove.
      65163f8c
    • unknown's avatar
      1b38c0b2
    • unknown's avatar
      Updated mysql.spec.sh file for br16298542 · 8237a8e3
      unknown authored
      8237a8e3
    • Marc Alff's avatar
      Bug#16414644 ASSERTION FAILED: SIZE == PFS_ALLOCATED_MEMORY · 7bdedb0c
      Marc Alff authored
      Before this fix, the command
        SHOW ENGINE PERFORMANCE_SCHEMA STATUS
      could report wrong amount of memory allocated,
      when the amount of memory used exceeds 4GB.
      
      The problem is that size computations are not done using size_t,
      so that overflows do occur, truncating the results.
      
      This fix compute memory sizes properly with size_t.
      
      Tested manually.
      
      No test script provided, as the script would need to allocate too much 
      memory for the test.
      7bdedb0c
    • unknown's avatar
      No commit message · 659e59d0
      unknown authored
      No commit message
      659e59d0
    • unknown's avatar
      No commit message · ccb0a18f
      unknown authored
      No commit message
      ccb0a18f
    • unknown's avatar
      No commit message · 4c031527
      unknown authored
      No commit message
      4c031527
  5. 27 Feb, 2013 5 commits
    • Gleb Shchepa's avatar
      Manual up-merge (16311231 backport) · 683015f6
      Gleb Shchepa authored
      683015f6
    • Gleb Shchepa's avatar
      Bug #16311231: MISSING DATA ON SUBQUERY WITH WHERE + XOR · 637a26f9
      Gleb Shchepa authored
      IN IN-CLAUSE USING MYISAM OR MEMORY ENGINE
      
      Backport from 5.6. Original message:
      
      The coincidences caused a data loss:
      * The query has IN subqueries nested twice,
      * the WHERE clause of the inner subquery refers to the
        outer field, and the whole WHERE clause returns FALSE,
      * the inner subquery has a LEFT JOIN that joins a single
        row with a row of NULLs; one of that NULL columns
        represents the select list of the subquery.
      
      Normally, that inner subquery should return empty record set.
      However, in our case:
      * the Item_is_not_null_test item goes constant, since
        its underlying field is NULL (because of LEFT JOIN ... ON 
        FALSE of const table row with a row of nulls);
      * we evaluate Item_is_not_null_test::val_int() as a part
        of fake HAVING expression of the transformed subquery;
      * as far as the underlying field is NULL, we optimize
        out the whole fake HAVING expression as FALSE as well
        as a whole subquery with a zero result:
        Impossible HAVING noticed after reading const tables";
      * thus, the optimizer ignores the presence of the WHERE
        clause (the WHERE expression is FALSE in our case, so
        the subquery should return empty set);
      * however, during the evaluation of the 
        Item_is_not_null_test::val_int() in the optimizer,
        it marked its "owner" with the "was_null" flag -- that
        forced the subquery to return UNKNOWN instead of empty
        set.
      That caused a wrong result.
      
      
      The problem is a regression of the small cleanup in
      the fix for the bug11827369 (the Item_is_not_null_test part)
      that conflicts with optimizations in the fix for the bug11752543.
      Before that regression the Item_is_not_null_test items
      never were constants.
      
      The fix is the rollback of Item_is_not_null_test parts
      of the bug11827369 fix.
      637a26f9
    • unknown's avatar
      Bug #16305265 HANG IN RENAME TABLE · e1d5e5cd
      unknown authored
      This is a deadlock that will also be fixed in the server by
      Bug #11844915 - HANG IN THDVAR MUTEX ACQUISITION.
      So this is a simple alternate method of fixing the same problem,
      but from within InnoDB.
      
      The simple change is to make rename table start a transaction
      before locking dict_sys->mutex since thd_supports_xa() can call
      THDVAR which can lock a mutex, LOCK_global_system_variables, that
      is used in the server by many other activities.  At least one of
      those, sys_var::update(), can call back into InnoDB and try to
      lock dict_sys->mutex while holding LOCK_global_system_variables.
      
      The other bug fix for 11844915 eliminates the use of
      LOCK_global_system_variables for calls to THDVAR.
      
      Approved by marko in http://rb.no.oracle.com/rb/r/2000/
      e1d5e5cd
    • Marko Mäkelä's avatar
      Merge mysql-5.1 to mysql-5.5. · f05b0d9c
      Marko Mäkelä authored
      f05b0d9c
    • Marko Mäkelä's avatar
      Bug#16400920 INNODB TRIES TO PASS EMPTY BUFFER TO ZLIB, GETS Z_BUF_ERROR · 5b6b89b4
      Marko Mäkelä authored
      page_zip_compress_node_ptrs(): Do not attempt to invoke deflate() with
      c_stream->avail_in, because it will result in Z_BUF_ERROR (and
      page_zip_compress() failure and unnecessary further splits of the node
      pointer page). A node pointer record can have empty payload, provided
      that all key fields are empty.
      
      Approved by Jimmy Yang
      5b6b89b4
  6. 26 Feb, 2013 2 commits
  7. 25 Feb, 2013 2 commits
  8. 26 Feb, 2013 2 commits
  9. 25 Feb, 2013 3 commits
    • Akhila Maddukuri's avatar
      cb68b9cc
    • unknown's avatar
      No commit message · 5f8472d3
      unknown authored
      No commit message
      5f8472d3
    • Annamalai Gurusami's avatar
      Bug #16044655 CRASH: SETTING DEFAULT VALUE FOR SOME VARIABLES · 48a405c4
      Annamalai Gurusami authored
      Problem:
      
      When a system variable is being set to the DEFAULT value, the server
      segfaults if there is no 'default' defined for that system variable.
      For example, for the following statements server segfaults.
      
      set session rand_seed1=DEFAULT;
      set session rand_seed2=DEFAULT;
      
      Analysis:
      
      The class sys_var represents one system variable.  The class set_var represents
      one system variable that is to be updated.   The class set_var contains two 
      pieces of information, the system variable to object (set_var::var) member
      and the value to be updated (set_var::value).
      
      When the given value is 'default', the set_var::value will be NULL.
      
      To update a system variable the member set_var::update() will be called, 
      which in turn will call sys_var::update() or sys_var::set_default() depending
      on whether a value has been provided or not.  
      
      If the sys_var::set_default() is called, then the default value is obtained
      either from the session scope or the global scope.  This default value is
      stored in a local temporary set_var object and then passed on to the 
      sys_var::update() call.  A local temporary set_var object is needed because
      sys_var::set_default() does not take set_var as an argument.
      
      In the given scenario, the set_var::update() called sys_var::set_default().
      And this sys_var::set_default() obtains the default value and then calls
      sys_var::update().  To pass this value to sys_var::update() a local set_var
      object is being created.   While creating this local set_var object, its member
      set_var::var was incorrectly left as 0.  
      
      Solution:
      
      Instead of creating a local set_var object, the sys_var::set_default() can take
      the set_var object as an argument just like sys_var::update().
      
      rb://1996 approved by Nirbhay and Ramil.
      
      48a405c4
  10. 23 Feb, 2013 3 commits
  11. 22 Feb, 2013 5 commits
    • Satya Bodapati's avatar
      Testcase fix for Bug#14147491 · 88a6b401
      Satya Bodapati authored
      Sleep 1sec before remove_file to solve windows pb2 issues. We hope that
      after sleep, the access to the file will not be denied.
      88a6b401
    • unknown's avatar
      43cb5b35
    • Daniel Fischer's avatar
      merge · 5cb7a77b
      Daniel Fischer authored
      5cb7a77b
    • Annamalai Gurusami's avatar
      Merge from mysql-5.1 to mysql-5.5 · 7cac7d8c
      Annamalai Gurusami authored
      7cac7d8c
    • Annamalai Gurusami's avatar
      Bug #14211565 CRASH WHEN ATTEMPTING TO SET SYSTEM VARIABLE TO RESULT OF VALUES() · 31413eef
      Annamalai Gurusami authored
      Problem:
      
      When the VALUES() function is inappropriately used in the SET stmt the server
      exits.  
      
      set port = values(v);
      
      This happens because the values(v) will be parsed as an Item_insert_value by
      the parser.  Both Item_field and Item_insert_value return the type as
      FIELD_ITEM.  But for Item_insert_value the field_name member is NULL.  In
      set_var constructor, when the type of the item is FIELD_ITEM we try to access
      the non-existent field_name. 
      
      The class hierarchy is as follows:
      Item -> Item_ident -> Item_field -> Item_insert_value
      
      The Item_ident::field_name is NULL for Item_insert_value.  
      
      Solution:
      
      In the parsing stage, in the set_var constructor if the item type is
      FIELD_ITEM and if the field_name is non-existent, then it is probably
      the Item_insert_value.  So leave it as it is for later evaluation.
      
      rb://2004 approved by Roy and Norvald.
      
      31413eef
  12. 20 Feb, 2013 2 commits
  13. 21 Feb, 2013 1 commit
  14. 20 Feb, 2013 1 commit