1. 28 Feb, 2013 4 commits
    • Marc Alff's avatar
      Bug#16414644 ASSERTION FAILED: SIZE == PFS_ALLOCATED_MEMORY · 99f83c66
      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.
      99f83c66
    • unknown's avatar
      No commit message · 94b1b653
      unknown authored
      No commit message
      94b1b653
    • unknown's avatar
      No commit message · d5f292de
      unknown authored
      No commit message
      d5f292de
    • unknown's avatar
      No commit message · 6ba3d9b8
      unknown authored
      No commit message
      6ba3d9b8
  2. 27 Feb, 2013 5 commits
    • Gleb Shchepa's avatar
      Manual up-merge (16311231 backport) · 93c93592
      Gleb Shchepa authored
      93c93592
    • Gleb Shchepa's avatar
      Bug #16311231: MISSING DATA ON SUBQUERY WITH WHERE + XOR · f8cd565d
      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.
      f8cd565d
    • unknown's avatar
      Bug #16305265 HANG IN RENAME TABLE · e1e43631
      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/
      e1e43631
    • Marko Mäkelä's avatar
      Merge mysql-5.1 to mysql-5.5. · a0d7f34b
      Marko Mäkelä authored
      a0d7f34b
    • Marko Mäkelä's avatar
      Bug#16400920 INNODB TRIES TO PASS EMPTY BUFFER TO ZLIB, GETS Z_BUF_ERROR · d065d727
      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
      d065d727
  3. 26 Feb, 2013 2 commits
  4. 25 Feb, 2013 2 commits
  5. 26 Feb, 2013 2 commits
  6. 25 Feb, 2013 3 commits
    • Akhila Maddukuri's avatar
      13058fd5
    • unknown's avatar
      No commit message · 698d2f10
      unknown authored
      No commit message
      698d2f10
    • Annamalai Gurusami's avatar
      Bug #16044655 CRASH: SETTING DEFAULT VALUE FOR SOME VARIABLES · 436d8402
      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.
      
      436d8402
  7. 23 Feb, 2013 3 commits
  8. 22 Feb, 2013 5 commits
    • Satya Bodapati's avatar
      Testcase fix for Bug#14147491 · 57674d63
      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.
      57674d63
    • unknown's avatar
      04780043
    • Daniel Fischer's avatar
      merge · eac8f5a1
      Daniel Fischer authored
      eac8f5a1
    • Annamalai Gurusami's avatar
      Merge from mysql-5.1 to mysql-5.5 · 64c5c5cb
      Annamalai Gurusami authored
      64c5c5cb
    • Annamalai Gurusami's avatar
      Bug #14211565 CRASH WHEN ATTEMPTING TO SET SYSTEM VARIABLE TO RESULT OF VALUES() · dc696973
      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.
      
      dc696973
  9. 20 Feb, 2013 2 commits
  10. 21 Feb, 2013 1 commit
  11. 20 Feb, 2013 1 commit
  12. 19 Feb, 2013 6 commits
    • Sujatha Sivakumar's avatar
      Merge from mysq-5.1 to mysql-5.5 · 1048aed5
      Sujatha Sivakumar authored
      1048aed5
    • Sujatha Sivakumar's avatar
      Bug#11746817:MYSQL_INSTALL_DB CREATES WILDCARD GRANTS WHEN · 4d494b17
      Sujatha Sivakumar authored
      HOST HAS '_' IN THE HOSTNAME
      
      Problem:
      =======
      '_' and '%' are treated as a wildcards by the ACL code and
      this is documented in the manual. The problem with
      mysql_install_db is that it does not take this into account
      when creating the initial GRANT tables:
      
      --- cut ---
      REPLACE INTO tmp_user SELECT @current_hostname,'root','','Y',
      'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y',
      'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','','','','',
      0,0,0,0 FROM dual WHERE LOWER( @current_hostname) != 'localhost';
      --- cut ---
      
      If @current_hostname contains any wildcard characters, then 
      a wildcard entry will be defined for the 'root' user, 
      which is a flaw.
      
      Analysis:
      ========
      As per the bug description when we have a hostname with a
      wildcard character in it, it allows clients from several other
      hosts with similar name pattern to connect to the server as root.
      For example, if the hostname is like 'host_.com' then the same
      name is logged in mysql.user table. This allows 'root' users
      from other hosts like 'host1.com', 'host2.com' ... to connect
      to the server as root user.
      
      While creating the intial GRANT tables we do not have a check
      for wildcard characters in hostname.
      
      Fix:
      ===
      As part of fix escape character "\" is added before wildcard
      character to make it a plain character, so that the one and
      only host with the exact name will be able to connect to the
      server.
      
      scripts/mysql_system_tables_data.sql:
        while creating default users get the hostname and
        replace the wildcard characters within the hostname after
        escaping them.
      4d494b17
    • Harin Vadodaria's avatar
      Bug#16235681: TURN OFF DEFAULT COMPRESSION WHILE USING · cc85d62c
      Harin Vadodaria authored
                    OPENSSL
      
      Description: Merge from 5.1.
      cc85d62c
    • Harin Vadodaria's avatar
      Bug#16235681: TURN OFF DEFAULT COMPRESSION WHILE USING · c4013654
      Harin Vadodaria authored
                    OPENSSL
      
      Description: Specify preference to disable compression
                   while using OpenSSL library. OpenSSL uses
                   zlib compression by default which may
                   lead to some problems.
      c4013654
    • Annamalai Gurusami's avatar
      9a989c57
    • unknown's avatar
      No commit message · 8ea6ed92
      unknown authored
      No commit message
      8ea6ed92
  13. 18 Feb, 2013 4 commits
    • Shivji Kumar Jha's avatar
      BUG#15965353- RPL.RPL_ROW_UNTIL FAILS ON PB2, · 85c299dd
      Shivji Kumar Jha authored
                    PLATFORM= MACOSX10.6 X86_64 MAX
      
                  post push fix
      85c299dd
    • Pedro Gomes 's avatar
    • Pedro Gomes 's avatar
      BUG#13545447: RPL_ROTATE_LOGS FAILS DUE TO CONCURRENCY ISSUES IN REP. CODE · e8e63d46
      Pedro Gomes authored
      Post-push fix, broken build:
      sql/rpl_master.cc:1049:70: error: converting ‘false’ to pointer type ‘bool*’ [-Werror=conversion-null]
      e8e63d46
    • Anirudh Mangipudi's avatar
      Bug #12546953 "SHOW VARIABLES LIKE 'DATADIR';" RETURN EMPTY. · 4061d719
      Anirudh Mangipudi authored
      Problem:
      ===========================================================
      If mysqld daemon is started without a --datadir option
      option, and we issue the SHOW VARIABLES LIKE 'DATADIR';SQL command
      at the client it returns an empty path. This is because
      mysql_real_data_home_ptr is being reset to NULL by Sys_var_charptr
      constructor call when the datadir is not given either through
      configuration file (no-defaults) or through mysqld parameters.
      
      Solution:
      ===========================================================
      mysql_real_data_home is an array which stores the path of the datadir
      and mysql_real_data_home_ptr is the pointer to it. The pointer is
      being set to NULL at the Sys_datadir, which is of type Sys_var_charptr,
      constructor call. This is because at Sys_datadir call the def_val 
      parameter was being passed with DEFAULT(0) which is now replaced with
      DEFAULT(mysql_real_data_home). The patch has been tested manually as it
      is not possible to start mtr without a default config file.
      4061d719