1. 12 Sep, 2013 3 commits
  2. 11 Sep, 2013 1 commit
    • Satya Bodapati's avatar
      Bug#16752251 - INNODB DOESN'T REDO-LOG INSERT BUFFER MERGE OPERATION IF · f166ec71
      Satya Bodapati authored
      	       IT IS DONE IN-PLACE
      
      With change buffer enabled, InnoDB doesn't write a transaction log
      record when it merges a record from the insert buffer to an secondary
      index page if the insertion is performed as an update-in-place.
      
      Fixed by logging the 'update-in-place' operation on secondary index
      pages.
      
      Approved by Marko. rb#2429
      f166ec71
  3. 10 Sep, 2013 2 commits
  4. 11 Sep, 2013 1 commit
  5. 10 Sep, 2013 6 commits
  6. 09 Sep, 2013 4 commits
  7. 06 Sep, 2013 1 commit
  8. 05 Sep, 2013 2 commits
  9. 04 Sep, 2013 1 commit
    • Neeraj Bisht's avatar
      Bug#17222452 - SELECT COUNT(DISTINCT A,B) INCORRECTLY COUNTS ROWS · 6a23a444
      Neeraj Bisht authored
      	       CONTAINING NULL
      
      Problem:-
      In MySQL, We can obtain the number of distinct expression
      combinations that do not contain NULL by giving a list of 
      expressions in COUNT(DISTINCT).
      However rows with NULL values are
      incorrectly included in the count when loose index scan is 
      used.
      
      Analysis:-
      In case of loose index scan, we check whether the field is null or 
      not and increase the count in Item_sum_count::add().
      But there we are checking for the first field in COUNT(DISTINCT), 
      not for every field. This is causing an incorrect result.
      
      Solution:-
      Check all field in Item_sum_count::add(), whether there values 
      are null or not. Then only increment the count.
      ******
      Bug#17222452 - SELECT COUNT(DISTINCT A,B) INCORRECTLY COUNTS ROWS 
      	       CONTAINING NULL
      
      Problem:-
      In MySQL, We can obtain the number of distinct expression
      combinations that do not contain NULL by giving a list of 
      expressions in COUNT(DISTINCT).
      However rows with NULL values are
      incorrectly included in the count when loose index scan is 
      used.
      
      Analysis:-
      In case of loose index scan, we check whether the field is null or 
      not and increase the count in Item_sum_count::add().
      But there we are checking for the first field in COUNT(DISTINCT), 
      not for every field. This is causing an incorrect result.
      
      Solution:-
      Check all field in Item_sum_count::add(), whether there values 
      are null or not. Then only increment the count.
      6a23a444
  10. 02 Sep, 2013 1 commit
    • Arun Kuruvila's avatar
      Bug #17168602 MYSQL_PLUGIN REMOVES NON-DIRECTORY TYPE FILES · 5b333350
      Arun Kuruvila authored
                    SPECIFIED WITH THE BASEDIR OPTION
      
      Description: The mysql_plugin client attempts to remove any
      filename specified to the --basedir option. The problem is 
      that if the filename does not end with a slash, it will 
      attempt to unlink it, which succeeds for files, but not for 
      directories.
      
      Analysis: When we are starting mysql_plugin with basedir 
      option and if we are giving path of a file as basedir, it 
      deletes that file. It was because it uses a function 
      my_delete which unlinks the file path given.
      
      Fix:  As a fix we replace that line using another function 
      my_free, which will only free the  pointer which is having 
      that file path.
      5b333350
  11. 01 Sep, 2013 1 commit
  12. 30 Aug, 2013 3 commits
  13. 28 Aug, 2013 3 commits
    • Raghav Kapoor's avatar
      BUG#17294150-POTENTIAL CRASH DUE TO BUFFER OVERRUN IN SSL · efb6a1d0
      Raghav Kapoor authored
                   ERROR HANDLING CODE 
      
      BACKGROUND:
      There can be a potential crash due to buffer overrun in 
      SSL error handling code due to missing comma in
      ssl_error_string[] array in viosslfactories.c.
      
      ANALYSIS:
      Found by code Inspection.
      
      FIX:
      Added the missing comma in SSL error handling code
      in ssl_error_string[] array in viosslfactories.c.
      efb6a1d0
    • Raghav Kapoor's avatar
      BUG#17294150-POTENTIAL CRASH DUE TO BUFFER OVERRUN IN SSL · c53cad81
      Raghav Kapoor authored
                   ERROR HANDLING CODE 
      
      BACKGROUND:
      There can be a potential crash due to buffer overrun in 
      SSL error handling code due to missing comma in
      ssl_error_string[] array in viosslfactories.c.
      
      ANALYSIS:
      Found by code Inspection.
      
      FIX:
      Added the missing comma in SSL error handling code
      in ssl_error_string[] array in viosslfactories.c.
      c53cad81
    • Neeraj Bisht's avatar
      Bug#16346241 - SERVER CRASH IN ITEM_PARAM::QUERY_VAL_STR · d4b4c827
      Neeraj Bisht authored
      Problem:-
      Second execution of prepared statement for query with 
      parameter in limit clause, causes an assert when using 
      connectors (e.g., Connector C).  
      
      
      Analysis:-
      In prepared statement, LIMIT parameters can be
      specified using '?' markers. Value for the parameter can
      be supplied while executing the prepared statement.
      
      Passing string, float or double values for LIMIT clause
      works well from command-line client. That's because, while 
      setting the LIMIT parameter value from a user-variable,
      the value is converted to integer value.
      
      However, when prepared statement is executed from other
      interfaces as J connectors, or C applications etc,
      the value for the parameters are sent to the server
      with execute command. Each item in command has value and
      the data TYPE. So, while setting parameter values
      from this log, value is set to all the parameters
      with the same data type as passed.
      Here, we have the logic to convert the value to change the 
      state and item_type if it is part of LIMIT parameter and 
      its item_type is not INT.
      But when we reset this parameter we save the item_type but change 
      state. So on second execution we have old item_type but our state 
      has been changed, which make us to use string type variable 
      in Item_param::query_str_val(). This cause an assert.
      
      Fix:
      Instead of checking the item_type of the parameter, check for 
      the state of the parameter. As state value are reset everytime
      we execute the statement.
      d4b4c827
  14. 27 Aug, 2013 1 commit
  15. 26 Aug, 2013 3 commits
    • Hery Ramilison's avatar
      Empty version change upmerge · c8cc4fc7
      Hery Ramilison authored
      c8cc4fc7
    • hery.ramilison@oracle.com's avatar
      242c82b6
    • Dmitry Lenev's avatar
      Fix for bug #17356954 "CANNOT USE SAVEPOINTS AFTER ER_LOCK_DEADLOCK OR · 45824782
      Dmitry Lenev authored
      ER_LOCK_WAIT_TIMEOUT".
      
      The problem was that after changes caused by fix bug 14188793 "DEADLOCK
      CAUSED BY ALTER TABLE DOEN'T CLEAR STATUS OF ROLLBACKED TRANSACTION"/
      bug 17054007 "TRANSACTION IS NOT FULLY ROLLED BACK IN CASE OF INNODB
      DEADLOCK implicit rollback of transaction which occurred on ER_LOCK_DEADLOCK
      (and ER_LOCK_WAIT_TIMEOUT if innodb_rollback_on_timeout option was set)
      didn't start new transaction in @@autocommit=1 mode.
      
      Such behavior although consistent with behavior of explicit ROLLBACK has
      broken expectations of users and backward compatibility assumptions.
      
      This patch fixes problem by reverting to starting new transaction
      in 5.5/5.6.
      
      The plan is to keep new behavior in trunk so the code change from this
      patch is to be null-merged there.
      45824782
  16. 23 Aug, 2013 7 commits
    • Praveenkumar Hulakund's avatar
      Bug#11765252 - READ OF FREED MEMORY WHEN "USE DB" AND · 45daf55a
      Praveenkumar Hulakund authored
                     "SHOW PROCESSLIST"
      
      Follow up path, addressing pb2 test failure.
      45daf55a
    • Praveenkumar Hulakund's avatar
    • mysql-builder@oracle.com's avatar
      No commit message · d8d64f90
      mysql-builder@oracle.com authored
      No commit message
      d8d64f90
    • Neeraj Bisht's avatar
      Bug#17029399 - CRASH IN ITEM_REF::FIX_FIELDS WITH TRIGGER ERRORS · 0cf9f5e7
      Neeraj Bisht authored
      Problem:-
      In a Procedure, when we are comparing value of select query 
      with IN clause and they both have different collation, cause 
      error on first time execution and assert second time.
      procedure will have query like
      set @x = ((select a from t1) in (select d from t2));<---proc1
                    sel1                   sel2
      
      Analysis:-
      When we execute this proc1(first time)
      While resolving the fields of user variable, we will call 
      Item_in_subselect::fix_fields while will resolve sel2. There 
      in Item_in_subselect::select_transformer, we evaluate the 
      left expression(sel1) and store it in Item_cache_* object 
      (to avoid re-evaluating it many times during subquery execution) 
      by making Item_in_optimizer class.
      While evaluating left expression we will prepare sel1.
      After that, we will put a new condition in sel2  
      in Item_in_subselect::select_transformer() which will compare 
      t2.d and sel1(which is cached in Item_in_optimizer).
      
      Later while checking the collation in agg_item_collations() 
      we get error and we cleanup the item. While cleaning up we cleaned 
      the cached value in Item_in_optimizer object.
      
      When we execute the procedure second time, we have condition for 
      sel2 and while setup_cond(), we can't able to find reference item 
      as it is cleanup while item cleanup.So it assert.
      
      
      Solution:-
      We should not cleanup the cached value for Item_in_optimizer object, 
      if we have put the condition to subselect.
      0cf9f5e7
    • Neeraj Bisht's avatar
      Bug#17029399 - CRASH IN ITEM_REF::FIX_FIELDS WITH TRIGGER ERRORS · 4f0e7c03
      Neeraj Bisht authored
      Problem:-
      In a Procedure, when we are comparing value of select query 
      with IN clause and they both have different collation, cause 
      error on first time execution and assert second time.
      procedure will have query like
      set @x = ((select a from t1) in (select d from t2));<---proc1
                    sel1                   sel2
      
      Analysis:-
      When we execute this proc1(first time)
      While resolving the fields of user variable, we will call 
      Item_in_subselect::fix_fields while will resolve sel2. There 
      in Item_in_subselect::select_transformer, we evaluate the 
      left expression(sel1) and store it in Item_cache_* object 
      (to avoid re-evaluating it many times during subquery execution) 
      by making Item_in_optimizer class.
      While evaluating left expression we will prepare sel1.
      After that, we will put a new condition in sel2  
      in Item_in_subselect::select_transformer() which will compare 
      t2.d and sel1(which is cached in Item_in_optimizer).
      
      Later while checking the collation in agg_item_collations() 
      we get error and we cleanup the item. While cleaning up we cleaned 
      the cached value in Item_in_optimizer object.
      
      When we execute the procedure second time, we have condition for 
      sel2 and while setup_cond(), we can't able to find reference item 
      as it is cleanup while item cleanup.So it assert.
      
      
      Solution:-
      We should not cleanup the cached value for Item_in_optimizer object, 
      if we have put the condition to subselect.
      
      4f0e7c03
    • mysql-builder@oracle.com's avatar
      No commit message · 29342a3c
      mysql-builder@oracle.com authored
      No commit message
      29342a3c
    • mysql-builder@oracle.com's avatar
      No commit message · 5e2694ea
      mysql-builder@oracle.com authored
      No commit message
      5e2694ea