1. 08 Oct, 2015 4 commits
  2. 06 Oct, 2015 5 commits
  3. 30 Sep, 2015 1 commit
  4. 29 Sep, 2015 1 commit
  5. 28 Sep, 2015 2 commits
  6. 27 Sep, 2015 2 commits
  7. 25 Sep, 2015 2 commits
  8. 24 Sep, 2015 2 commits
  9. 18 Sep, 2015 2 commits
  10. 07 Sep, 2015 1 commit
  11. 04 Sep, 2015 1 commit
  12. 26 Aug, 2015 1 commit
  13. 25 Aug, 2015 1 commit
  14. 21 Aug, 2015 1 commit
    • Arun Kuruvila's avatar
      Bug#20198490 : LOWER_CASE_TABLE_NAMES=0 ON WINDOWS LEADS TO · f4ff086a
      Arun Kuruvila authored
                     PROBLEMS
      
      Description:- Server variable "--lower_case_tables_names"
      when set to "0" on windows platform which does not support
      case sensitive file operations leads to problems. A warning
      message is printed in the error log while starting the
      server with "--lower_case_tables_names=0". Also according to
      the documentation, seting "lower_case_tables_names" to "0"
      on a case-insensitive filesystem might lead to index
      corruption.
      
      Analysis:- The problem reported in the bug is:-
      Creating an INNODB table 'a' and executing a query, "INSERT
      INTO a SELECT a FROM A;" on a server started with
      "--lower_case_tables_names=0" and running on a
      case-insensitive filesystem leads innodb to flat spin.
      Optimizer thinks that "a" and "A" are two different tables
      as the variable "lower_case_table_names" is set to "0". As a
      result, optimizer comes up with a plan which does not need a
      temporary table. If the same table is used in select and
      insert, a temporary table is needed. This incorrect
      optimizer plan leads to infinite insertions.
      
      Fix:- If the server is started with
      "--lower_case_tables_names" set to 0 on a case-insensitive
      filesystem, an error, "The server option
      'lower_case_table_names'is configured to use case sensitive
      table names but the data directory is on a case-insensitive
      file system which is an unsupported combination. Please
      consider either using a case sensitive file system for your
      data directory or switching to a case-insensitive table name
      mode.", is printed in the server error log and the server
      exits.
      f4ff086a
  15. 19 Aug, 2015 1 commit
  16. 18 Aug, 2015 2 commits
    • Shishir Jaiswal's avatar
      Bug #16171518 - LOAD XML DOES NOT HANDLE EMPTY ELEMENTS · ee02650b
      Shishir Jaiswal authored
      DESCRIPTION
      ===========
      Inability of mysql LOAD XML command to handle empty XML
      tags i.e. <row><tag/></row>. Also the behaviour is wrong
      and (different than above) when there is a space in empty
      tag i.e. <row><tag /></row>
      
      ANALYSIS
      ========
      In read_xml() the case where we encounter a close tag ('/')
      we're decreasing the 'level' blindly which is wrong.
      Actually when its an without-space-empty-tag (succeeding
      char is '>'), we need to skip the decrement. In other words
      whenever we hit a close tag ('/'), decrease the 'level'
      only when (i) It's not an (without space) empty tag i.e.
      <tag/> or, (ii) It is of format <row col="val" .../>
      
      FIX
      ===
      The switch case for '/' is modified. We've removed the
      blind decrement of 'level'. We do it only when its not an
      without-space-empty-tag. Also we are setting 'in_tag' to
      false to let program know that we're done reading current
      tag (required in the case of format <row col="val" .../>)
      ee02650b
    • Karthik Kamath's avatar
      BUG#11754258: INCORRECT ERROR MESSAGE WHEN CREATING UNSAFE · 93ac0eb1
      Karthik Kamath authored
                    VIEW
      
      
      It appears that the code refactoring done as part of the
      patch for the MySQL BUG#11749859 fixed this issue. This
      issue is not reproducible on MySQL 5.5+ versions now.
      As part of this patch, the test file "mysqldump.test" has
      been updated to remove the comment which was referring to
      the bug and also the line which suppresses the warning.
      93ac0eb1
  17. 17 Aug, 2015 2 commits
    • Mithun C Y's avatar
      Merge branch 'mysql-5.1' into mysql-5.5 · 8fe07088
      Mithun C Y authored
      8fe07088
    • Mithun C Y's avatar
      Bug #21350175: SUBQUERIES IN PROCEDURE CLAUSE OF SELECT STATEMENT CAUSES SERVER FAILURES. · 557a57f3
      Mithun C Y authored
      Analysis :
      ==========
      During JOIN::prepare of sub-query which creates the
      derived tables we call setup_procedure. Here we call
      fix_fields for parameters of procedure clause. Calling
      setup_procedure at this point may cause issue. If
      sub-query is one of parameter being fixed it might
      lead to complicated dependencies on derived tables
      being prepared.
      
      SOLUTION :
      ==========
      In 5.6 with WL#6242, we have made procedure clause
      parameters can only be NUM, so sub-queries are not
      allowed as parameters. So in 5.5 we can block
      sub-queries in procedure clause parameters.
      This eliminates above conflicting dependencies.
      557a57f3
  18. 12 Aug, 2015 1 commit
    • Aditya A's avatar
      Bug #21025880 DUPLICATE UK VALUES IN READ-COMMITTED (AGAIN) · 608efca4
      Aditya A authored
      PROBLEM
      
      Whenever we insert in unique secondary index we take shared
      locks on all possible duplicate record present in the table.
      But while during a replace on the unique secondary index ,
      we take exclusive and locks on the all duplicate record.
      When the records are deleted, they are first delete marked
      and later purged by the purge thread. While purging the
      record we call the lock_update_delete() which in turn calls
      lock_rec_inherit_to_gap() to inherit locks of the deleted
      records. In repeatable read mode we inherit all the locks
      from the record to the next record  but in the read commited
      mode we skip inherting them as gap type locks. We make a
      exception here if the lock on the records is  in shared mode
      ,we assume that it is set during insert for unique secondary
      index and needs to be inherited to stop constraint violation.
      We didnt handle the case when exclusive locks are set during
      replace, we skip inheriting locks of these records and hence
      causing constraint violation.
      
      FIX
      
      While inheriting the locks,check whether the transaction is
      allowed to do TRX_DUP_REPLACE/TRX_DUP_IGNORE, if true
      inherit the locks.
      
      [ Revewied by Jimmy #rb9709]
      608efca4
  19. 10 Aug, 2015 1 commit
  20. 07 Aug, 2015 2 commits
    • Ajo Robert's avatar
      Merge branch 'mysql-5.1' into mysql-5.5 · 552b1c8a
      Ajo Robert authored
      552b1c8a
    • Ajo Robert's avatar
      Bug #20760261 mysqld crashed in materialized_cursor:: · f3dce250
      Ajo Robert authored
      send_result_set_metadata
      
      Analysis
      --------
      Cursor inside trigger accessing NEW/OLD row leads server exit.
      
      The reason for the bug was that implementation of function
      create_tmp_table() was not considering Item::TRIGGER_FIELD_ITEM
      as possible alternative for type of class being instantiated.
      This was resulting in a mismatch between a number of columns
      in result list and temp table definition. This mismatch leads
      to the failure of assertion
      DBUG_ASSERT(send_result_set_metadata.elements == item_list.elements)
      in the method Materialized_cursor::send_result_set_metadata
      in debug mode.
      
      Fix:
      ---
      Added code to consider Item::TRIGGER_FIELD_ITEM as valid
      type while creating fields.
      f3dce250
  21. 05 Aug, 2015 2 commits
  22. 04 Aug, 2015 3 commits