1. 03 Oct, 2012 1 commit
  2. 10 Sep, 2012 1 commit
    • Mattias Jonsson's avatar
      Bug#14495351: CRASH IN HA_PARTITION::HANDLE_UNORDERED_NEXT · 7113d5d3
      Mattias Jonsson authored
      The partitioning engine does not implement index_next for partitions
      which return HA_ERR_KEY_NOT_FOUND in index_read_map.
      
      If HA_ERR_KEY_NOT_FOUND was returned by a partition during
      index_read_map, that partition would not be included in following
      calls to index_next. If no partition returned a row in index_read_map,
      then the subsequent call to index_next would try to use a non existing
      handler (index out of bound).
      Even after fixing the index out of bound if at least one partition
      returned.
      
      So it is really two connected bugs
      1) crash due to index out of bound (-1 unsigned).
      2) not including partitions that returned HA_ERR_KEY_NOT_FOUND.
      
      Fixed by recording the partitions that returned HA_ERR_KEY_NOT_FOUND,
      and include them too when doing handle_ordered_next the first time.
      7113d5d3
  3. 02 Oct, 2012 1 commit
  4. 01 Oct, 2012 5 commits
  5. 28 Sep, 2012 2 commits
    • Annamalai Gurusami's avatar
      Merge from mysql-5.1 to mysql-5.5. · 83fb2c15
      Annamalai Gurusami authored
      83fb2c15
    • Annamalai Gurusami's avatar
      Bug #13249921 ASSERT !BPAGE->FILE_PAGE_WAS_FREED, USUALLY IN · c9e3a834
      Annamalai Gurusami authored
      TRANSACTION ROLLBACK
      
      Description:  During the rollback operation, a blob page 
      is removed earlier than desired.  Consider following scenario:
      
      1. create table t1(a int primary key,b blob) engine=innodb;
      2. insert into t1 values (1,repeat('b',9000));
      3. begin;
      4. update t1 set b=concat(b,'b');
      5. update t1 set a=a+1;
      6. insert into t1 values (1,repeat('b',9000));
      7. rollback;
      
      The update operation in line 5 produces 2 undo log record. The first
      undo record (TRX_UNDO_DEL_MARK_REC) goes to trx->update_undo and the
      second undo record (TRX_UNDO_INSERT_REC) goes to trx->insert_undo.
      During rollback, they are executed out of order.
      
      When the undo record TRX_UNDO_DEL_MARK_REC is applied/executed,
      the blob ownership is also reset.  Because of this the blob page
      is released earlier than desired.  This blob page must have been
      freed only as part of applying/executing the undo record
      TRX_UNDO_INSERT_REC.
      
      This problem can be avoided by executing the undo records in
      order.  This patch will make innodb to execute the undo records
      in order.
      
      rb://1125 approved by Marko.
      c9e3a834
  6. 27 Sep, 2012 1 commit
  7. 26 Sep, 2012 5 commits
    • Akhila Maddukuri's avatar
      Description: · 03818d96
      Akhila Maddukuri authored
      ```--------
      After compiling from source, during make test I got the following error:
      
      test main.loaddata failed with error
      CURRENT_TEST: main.loaddata
      mysqltest: At line 592: query 'LOAD DATA INFILE 'tmpp.txt' INTO TABLE t1
      CHARACTER SET ucs2
      (@b) SET a=REVERSE(@b)' failed: 1115: Unknown character set: 'ucs2'
      
      I noticed other tests are skipped because of no ucs2
      main.mix2_myisam_ucs2                    [ skipped ]  Test requires:'
      have_ucs2'
      
      Should main.loaddata be skipped if there is no ucs2
      
      How To Repeat:
      ```
      
      ----------
      Run make test on compiled source that doesn't have ucs2
      
      Suggested fix:
      -------------
      the failing piece of the test should be moved from mysql-test/t/loaddata.test to
      mysql-test/t/ctype_ucs.test.
      03818d96
    • unknown's avatar
      No commit message · d87e1b57
      unknown authored
      No commit message
      d87e1b57
    • unknown's avatar
      No commit message · d1006884
      unknown authored
      No commit message
      d1006884
    • Akhila Maddukuri's avatar
      Description: · 663753f6
      Akhila Maddukuri authored
      ```--------
      After compiling from source, during make test I got the following error:
      
      test main.loaddata failed with error
      CURRENT_TEST: main.loaddata
      mysqltest: At line 592: query 'LOAD DATA INFILE 'tmpp.txt' INTO TABLE t1
      CHARACTER SET ucs2
      (@b) SET a=REVERSE(@b)' failed: 1115: Unknown character set: 'ucs2'
      
      I noticed other tests are skipped because of no ucs2
      main.mix2_myisam_ucs2                    [ skipped ]  Test requires:'
      have_ucs2'
      
      Should main.loaddata be skipped if there is no ucs2
      
      How To Repeat:
      ```
      
      ----------
      Run make test on compiled source that doesn't have ucs2
      
      Suggested fix:
      -------------
      the failing piece of the test should be moved from mysql-test/t/loaddata.test to
      mysql-test/t/ctype_ucs.test.
      663753f6
    • Akhila Maddukuri's avatar
      Description: · 2bfcfcb4
      Akhila Maddukuri authored
      ```--------
      After compiling from source, during make test I got the following error:
      
      test main.loaddata failed with error
      CURRENT_TEST: main.loaddata
      mysqltest: At line 592: query 'LOAD DATA INFILE 'tmpp.txt' INTO TABLE t1
      CHARACTER SET ucs2
      (@b) SET a=REVERSE(@b)' failed: 1115: Unknown character set: 'ucs2'
      
      I noticed other tests are skipped because of no ucs2
      main.mix2_myisam_ucs2                    [ skipped ]  Test requires:'
      have_ucs2'
      
      Should main.loaddata be skipped if there is no ucs2
      
      How To Repeat:
      ```
      
      ----------
      Run make test on compiled source that doesn't have ucs2
      
      Suggested fix:
      -------------
      the failing piece of the test should be moved from mysql-test/t/loaddata.test to
      mysql-test/t/ctype_ucs.test.
      2bfcfcb4
  8. 25 Sep, 2012 10 commits
    • Tor Didriksen's avatar
      merge 5.1 => 5.5 · dc462ebd
      Tor Didriksen authored
      dc462ebd
    • Tor Didriksen's avatar
      Backport · b7169e68
      Tor Didriksen authored
      Bug #11764313 57135: CRASH IN ITEM_FUNC_CASE::FIND_ITEM WITH CASE WHEN
      Bug #11764818 57692: Crash in item_func_in::val_int() with ZEROFILL
      b7169e68
    • unknown's avatar
      No commit message · 24bfdab9
      unknown authored
      No commit message
      24bfdab9
    • unknown's avatar
      No commit message · 4631687d
      unknown authored
      No commit message
      4631687d
    • unknown's avatar
      No commit message · 139e950c
      unknown authored
      No commit message
      139e950c
    • unknown's avatar
      No commit message · 153d2468
      unknown authored
      No commit message
      153d2468
    • Jon Olav Hauglid's avatar
      Merge from mysql-5.1 to mysql-5.5 · ad814226
      Jon Olav Hauglid authored
      ad814226
    • Jon Olav Hauglid's avatar
      Bug#14621627 THREAD CACHE IS UNFAIR · cbe38f3a
      Jon Olav Hauglid authored
      When a client connects to a MySQL server, first a THD object is created.
      If there are any idle server threads waiting, the THD object is then added
      to a list and a server thread is woken up. This thread then retrieves the 
      THD object from the list and starts executing.
      
      The problem was that this list of THD objects waiting for a server thread,
      was not working in a FIFO fashion, but rather LIFO. This is unfair, as it means
      that the last THD added (=last client connected) will be assigned a  server 
      thread first.
      
      Note however that for this to be a problem, several clients must be able
      to connect and have THD objects constructed before any server threads
      manages to be woken up. This is not a very likely scenario.
      
      This patch fixes the problem by changing the THD list to work FIFO
      rather than LIFO.
      
      This is the 5.1/5.5 version of the patch.
      cbe38f3a
    • Raghav Kapoor's avatar
      BUG#13864642: DROP/CREATE USER BEHAVING ODDLY · f2f358c5
      Raghav Kapoor authored
      BACKGROUND:
      In certain situations DROP USER fails to remove all privileges
      belonging to user being dropped from in-memory structures.
      Current workaround is to do DROP USER twice in scenario below
      OR doing FLUSH PRIVILEGES after doing DROP USER.
      
      ANALYSIS:
      In MySQL, When we grant some stored routines privileges to a
      user they are stored in their respective hash.
      When doing DROP USER all the stored routine privilege entries
      associated with that user has to be deleted from its respective 
      hash.
      The root cause for this bug is some entries from the hash
      are not getting deleted. 
      The problem is that code that deletes entries from the hash tries
      to do so while iterating over it, without taking enough measures
      to address the fact that such deletion can reshuffle elements in 
      the hash. If the user/administrator creates the same user again 
      he is thrown an  error 'Error 1396 ER_CANNOT_USER' from MySQL.
      This prompts the user to either do FLUSH PRIVILEGES or do DROP USER 
      again. This behaviour is not desirable as it is a workaround and
      does not solves the problem mentioned above.
      
      FIX:
      This bug is fixed by introducing a dynamic array to store the 
      pointersto all stored routine privilege objects that either have
      to be deleted or updated. This is done in 3 steps.
      Step 1: Fetching the element from the hash and checking whether 
      it is to be deleted or updated.
      Step 2: Storing the pointer to that privilege object in dynamic array.
      Step 3: Traversing the dynamic array to perform the appropriate action 
      either delete or update.
      This is a much cleaner way to delete or update the privilege entries 
      associated with some user and solves the problem mentioned above.
      Also the code has been refactored a bit by introducing an enum
      instead of hard coded numbers used for respective dynamic arrays 
      and hashes in handle_grant_struct() function.
      f2f358c5
    • Raghav Kapoor's avatar
      BUG#13864642: DROP/CREATE USER BEHAVING ODDLY · d82962d5
      Raghav Kapoor authored
      BACKGROUND:
      In certain situations DROP USER fails to remove all privileges
      belonging to user being dropped from in-memory structures.
      Current workaround is to do DROP USER twice in scenario below
      OR doing FLUSH PRIVILEGES after doing DROP USER.
      
      ANALYSIS:
      In MySQL, When we grant some stored routines privileges to a
      user they are stored in their respective hash.
      When doing DROP USER all the stored routine privilege entries
      associated with that user has to be deleted from its respective 
      hash.
      The root cause for this bug is some entries from the hash
      are not getting deleted. 
      The problem is that code that deletes entries from the hash tries
      to do so while iterating over it, without taking enough measures
      to address the fact that such deletion can reshuffle elements in 
      the hash. If the user/administrator creates the same user again 
      he is thrown an  error 'Error 1396 ER_CANNOT_USER' from MySQL.
      This prompts the user to either do FLUSH PRIVILEGES or do DROP USER 
      again. This behaviour is not desirable as it is a workaround and
      does not solves the problem mentioned above.
      
      FIX:
      This bug is fixed by introducing a dynamic array to store the 
      pointersto all stored routine privilege objects that either have
      to be deleted or updated. This is done in 3 steps.
      Step 1: Fetching the element from the hash and checking whether 
      it is to be deleted or updated.
      Step 2: Storing the pointer to that privilege object in dynamic array.
      Step 3: Traversing the dynamic array to perform the appropriate action 
      either delete or update.
      This is a much cleaner way to delete or update the privilege entries 
      associated with some user and solves the problem mentioned above.
      Also the code has been refactored a bit by introducing an enum
      instead of hard coded numbers used for respective dynamic arrays 
      and hashes in handle_grant_struct() function.
      d82962d5
  9. 23 Sep, 2012 2 commits
  10. 22 Sep, 2012 2 commits
  11. 21 Sep, 2012 3 commits
    • Nirbhay Choubey's avatar
      0143bbf5
    • Nirbhay Choubey's avatar
      Bug#14645196 MYSQL CLIENT'S USE COMMAND FAILS · 221ba6c4
      Nirbhay Choubey authored
      WHEN DBNAME CONTAINS MULTIPLE QUOTES
      
      MySQL client's USE command might fail if the
      database name contains multiple quotes (backticks).
      
      The reason behind the failure being the method
      that client uses to remove/escape the quotes
      while parsing the USE command's option (dbname),
      where the option parsing might terminate if a
      matching quote is found.
      
      Also, C-APIs like mysql_select_db() expect a
      normalized dbname. Now, in certain cases, client
      might fail to normalize dbname similar to that of
      server and hence mysql_select_db() would fail.
      
      Fixed by getting the normalized dbname (indirectly)
      from the server by directly sending the "USE dbanme"
      as query to the server followed by a "SELECT DATABASE()".
      The above steps are only performed if number of quotes
      in the dbname is greater than 2. Once the normalized
      dbname is received, the original db is restored.
      221ba6c4
    • Joerg Bruehe's avatar
      Merge changes for ULN RPMs into main 5.5 · ab746e56
      Joerg Bruehe authored
      ab746e56
  12. 20 Sep, 2012 5 commits
  13. 19 Sep, 2012 2 commits
    • Marko Mäkelä's avatar
      Merge mysql-5.1 to mysql-5.5. · eb69278b
      Marko Mäkelä authored
      eb69278b
    • Marko Mäkelä's avatar
      Bug#14636528 INNODB CHANGE BUFFERING IS NOT ENTIRELY CRASH-SAFE · b3e0fa54
      Marko Mäkelä authored
      Delete-mark change buffer records when resorting to a pessimistic
      delete from the change buffer B-tree. Skip delete-marked records in
      the change buffer merge and when estimating whether an operation can
      be buffered. Without this fix, we could try to apply the same buffered
      changes multiple times if the server was killed at the right moment.
      
      In MySQL 5.5 and later: ibuf_get_volume_buffered_count_func(): Ignore
      delete-marked (already processed) records.
      
      ibuf_delete_rec(): Add a crash point before optimistic delete. If the
      optimistic delete fails, flag the record processed before
      mtr_commit().
      
      ibuf_merge_or_delete_for_page(): Ignore delete-marked (already
      processed) records.
      
      Backport to 5.1: Rename btr_cur_del_unmark_for_ibuf() to
      btr_cur_set_deleted_flag_for_ibuf() and add a parameter.
      
      rb:1307 approved by Jimmy Yang
      b3e0fa54