1. 21 Oct, 2012 1 commit
  2. 19 Oct, 2012 1 commit
  3. 18 Oct, 2012 2 commits
    • Neeraj Bisht's avatar
      Bug#13726751 - 8 BYTE MEMORY LEAK IN DO_SAVE_BLOB · 4aaadc12
      Neeraj Bisht authored
      Problem:-
      When we execute a query which has subquery with GROUP BY, ORDER BY and have a
      BLOB column,results a memory leak.
      
      Analysis:-
      In case of subquery, which have GROUP BY on BLOB and a ORDER BY on other field
      and BLOB is not a key. We allocate a tmp buffer to copy_field to take care of
      BLOB value.This copy_field value can have copies of its in two join(objects),
      so while freeing this copy_field we have to take care that it is
      not deleted twice.
      The double deletion of tmp_table_param.copy_field is handled by two patches.
      
      One by Kostja :
      revid:sp1r-konstantin@mysql.com-20050627101056-55153
      Fix the broken test suite in -debug build.
      
      and other by Oleksandr
      revid:sp1r-bell@sanja.is.com.ua-20060118114857-19905
      Excluded posibility of tmp_table_param.copy_field double deletion (BUG#14851).
      
      both of this patches are commited in different branch and while
      merging they both get placed,but there is no need for Kostja patch as Oleksandr
      patch handle this.
      4aaadc12
    • Marko Mäkelä's avatar
      Bug#14758405: ALTER TABLE: ADDING SERIAL NULL DATATYPE: ASSERTION: · 48519303
      Marko Mäkelä authored
      LEN <= SIZEOF(ULONGLONG)
      
      This bug was caught in the WL#6255 ALTER TABLE...ADD COLUMN in MySQL
      5.6, but there is a bug in all InnoDB versions that support
      auto-increment columns.
      
      row_search_autoinc_read_column(): When reading the maximum value of
      the auto-increment column, and the column only contains NULL values,
      return 0. This corresponds to the case when the table is empty in
      row_search_max_autoinc().
      
      rb:1415 approved by Sunny Bains
      48519303
  4. 17 Oct, 2012 4 commits
  5. 16 Oct, 2012 2 commits
    • Neeraj Bisht's avatar
      Bug#11745891 - LAST_INSERT(ID) DOES NOT SUPPORT BIGINT UNSIGNED · c55dd6bd
      Neeraj Bisht authored
      Problem:-
      using last_insert_id() on an auto_incremented bigint unsigned does
      not work for values which are greater than max-bigint-signed.
      
      Analysis:-
      last_insert_id() returns the first auto_incremented value for a column
      and an auto_incremented value can have only positive values.
      
      In our code, when we are initializing a last_insert_id object, we are
      taking it as a signed BIGINT, So when the auto_incremented value reaches
      greater than max signed bigint, last_insert_id gives negative result.
      
      Solution:
      When we are fetching the value from last_insert_id, We are setting the 
      unsigned_flag, so that it take only unsigned BIGINT value.
      c55dd6bd
    • Marko Mäkelä's avatar
      Bug#14729221 IN-PLACE ALTER TABLE REPORTS '' INSTEAD OF · b10ab56d
      Marko Mäkelä authored
      REAL DUPLICATE VALUE FOR PREFIX KEYS
      
      innobase_rec_to_mysql(): Invoke dict_index_get_nth_col_or_prefix_pos()
      instead of dict_index_get_nth_col_pos() to find the column.
      b10ab56d
  6. 15 Oct, 2012 1 commit
    • Krunal Bauskar krunal.bauskar@oracle.com's avatar
      · c8cebffd
      bug#14704286
      SECONDARY INDEX UPDATES MAKE CONSISTENT READS DO O(N^2) UNDO PAGE
      LOOKUPS (honoring kill query while accessing sec_index)
      
      If secondary index is being used for select query evaluation and this
      query is operating with consistent read snapshot it might take good time for
      secondary index to return back control to mysql as MVCC would kick in.
      
      If user issues "kill query <id>" while query is actively accessing
      secondary index it will not be honored as there is no hook to check
      for this condition. Added hook for this check.
      
      -----
      Parallely secondary index taking too long to evaluate for consistent
      read snapshot case is being examined for performance improvement. WL#6540.
      c8cebffd
  7. 12 Oct, 2012 2 commits
    • Marc Alff's avatar
      Bug#14629232 SECURITY VULNERABILITY WITH SHOW PROFILE · c8f6ab29
      Marc Alff authored
      This fix resolves a security vulnerability of SHOW PROFILE.
      
      See the bug report for details.
      c8f6ab29
    • Nuno Carvalho's avatar
      BUG#14629727: USER_VAR_EVENT IS MISSING RANGE CHECKS · 0cdd810b
      Nuno Carvalho authored
      This bug had two problems:
       P1) Reads out of bounds;
       P2) Writes out of bounds.
      
      PROBLEM P1
      ----------
      User_var_log_event unmarshalling from binlog was not performing range
      checks when using name_len and val_len variables to walk on event
      buffer.
      
      Added range checks to User_var_log_event unmarshalling to prevent
      unmarshalling errors.
      
      PROBLEM P2
      ----------
      User_var_log_event value was allocated on thread stack, what caused
      stack frame errors when User_var_log_event value was bigger than thread
      stack size.
      
      Currently value is allocated on heap memory.
      0cdd810b
  8. 10 Oct, 2012 1 commit
  9. 09 Oct, 2012 3 commits
  10. 08 Oct, 2012 1 commit
    • Marko Mäkelä's avatar
      Bug#14731482 UPDATE OR DELETE CORRUPTS A RECORD WITH A LONG PRIMARY KEY · be509b41
      Marko Mäkelä authored
      We did not allocate enough bits for index->trx_id_offset, causing an
      UPDATE or DELETE of a table with a PRIMARY KEY longer than 1024 bytes
      to corrupt the PRIMARY KEY.
      
      dict_index_t: Allocate enough bits.
      
      dict_index_build_internal_clust(): Check for overflow of
      index->trx_id_offset. Trip a debug assertion when overflow occurs.
      
      rb:1380 approved by Jimmy Yang
      be509b41
  11. 01 Oct, 2012 2 commits
  12. 28 Sep, 2012 1 commit
    • Annamalai Gurusami's avatar
      Bug #13249921 ASSERT !BPAGE->FILE_PAGE_WAS_FREED, USUALLY IN · 91c8a65a
      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.
      91c8a65a
  13. 26 Sep, 2012 2 commits
    • mysql-builder@oracle.com's avatar
      No commit message · f5daa878
      mysql-builder@oracle.com authored
      No commit message
      f5daa878
    • Akhila Maddukuri's avatar
      Description: · 39739a42
      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.
      39739a42
  14. 25 Sep, 2012 5 commits
    • Tor Didriksen's avatar
      Backport · abdb7906
      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
      abdb7906
    • mysql-builder@oracle.com's avatar
      No commit message · 862fc0f5
      mysql-builder@oracle.com authored
      No commit message
      862fc0f5
    • mysql-builder@oracle.com's avatar
      No commit message · 0a50d49c
      mysql-builder@oracle.com authored
      No commit message
      0a50d49c
    • Jon Olav Hauglid's avatar
      Bug#14621627 THREAD CACHE IS UNFAIR · 139c8ed5
      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.
      139c8ed5
    • Raghav Kapoor's avatar
      BUG#13864642: DROP/CREATE USER BEHAVING ODDLY · 5c089b08
      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.
      5c089b08
  15. 23 Sep, 2012 1 commit
  16. 22 Sep, 2012 1 commit
    • Rohit Kalhans's avatar
      BUG#14548159: NUMEROUS CASES OF INCORRECT IDENTIFIER · 5f003eca
      Rohit Kalhans authored
      QUOTING IN REPLICATION 
      
      Problem: Misquoting or unquoted identifiers may lead to
      incorrect statements to be logged to the binary log.
      
      Fix: we use specialized functions to append quoted identifiers in
      the statements generated by the server.
      5f003eca
  17. 21 Sep, 2012 1 commit
    • Nirbhay Choubey's avatar
      Bug#14645196 MYSQL CLIENT'S USE COMMAND FAILS · 600aa420
      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.
      600aa420
  18. 20 Sep, 2012 1 commit
  19. 19 Sep, 2012 1 commit
    • Marko Mäkelä's avatar
      Bug#14636528 INNODB CHANGE BUFFERING IS NOT ENTIRELY CRASH-SAFE · aed6b871
      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
      aed6b871
  20. 17 Sep, 2012 4 commits
    • Marko Mäkelä's avatar
      Merge mysql-5.1 to working copy. · bb57fd74
      Marko Mäkelä authored
      bb57fd74
    • Harin Vadodaria's avatar
      Bug#11753779: MAX_CONNECT_ERRORS WORKS ONLY WHEN 1ST · 9f072780
      Harin Vadodaria authored
                    INC_HOST_ERRORS() IS CALLED.
      
      Issue       : Sequence of calling inc_host_errors()
                    and reset_host_errors() required some
                    changes in order to maintain correct
                    connection error count.
      
      Solution    : Call to reset_host_errors() is shifted
                    to a location after which no calls to
                    inc_host_errors() are made.
      9f072780
    • Marko Mäkelä's avatar
      Bug#12701488 ASSERT PAGE_ZIP_VALIDATE, UNIV_ZIP_DEBUG · dc80dcac
      Marko Mäkelä authored
      page_zip_validate(), page_zip_validate_low(): Add a parameter for the
      B-tree index.
      
      page_zip_validate_low(): If the page contents does not match, check
      that the record link chains match. Furthermore, if dict_index_t is
      passed, check that the records match. (This reduces coverage a bit: if
      index=NULL, we will ignore differences in record contents, that is,
      the page payload.)
      
      rb:1264 approved by Inaam Rana
      dc80dcac
    • Sujatha Sivakumar's avatar
      Bug#11750014:ASSERTION TRX_DATA->EMPTY() IN BINLOG_CLOSE_CONNECTION · 4bfeb52d
      Sujatha Sivakumar authored
      Problem:
      =======
      
      trx_data->empty() assert happens at `binlog_close_connection'
      
      Analysis:
      ========
      
      trx_data->empty() function checks for no pending events
      and the transaction cache to be empty.This function returns
      "true" if no pending events are present and cache is empty.
      Otherwise it returns false. `binlog_close_connection' call
      expects the above function to return true. But if the
      return value is false then assert is raised.
      
      This bug was reproducible in a diskfull scenario. In this
      disk full scenario try to do an insert operation so that
      a new pending event is created and flushing this pending
      event fails. Due to this failure the server goes down
      and invokes `binlog_close_connection' for clean closure.
      Since the pending event still remains the assert is caused.
      This assert is caused only in non transactional databases.
      
      
      Fix:
      ===
      
      In a disk full scenario when the insertion fails the
      transaction is rolled back and `binlog_end_trans`
      is called to flush the pending events. But flush operation
      fails as the disk is full and the function simply returns
      `1' without taking any action to delete the pending event.
      
      This leaves the event to remain till the closure of
      connection.  `delete pending' statement has been added to 
      do the required clean up action.
      4bfeb52d
  21. 12 Sep, 2012 2 commits
  22. 11 Sep, 2012 1 commit
    • Joerg Bruehe's avatar
      Backport this change from MySQL 5.5 to 5.1: · c0a1b2c8
      Joerg Bruehe authored
        Bug #14181049: MYSQL_INSTALL_DB.PL CREATES EMPTY SYSTEM TABLES FOR MYSQL
      
        The script is different from what's used on unixes.
        It was not playing the table insertion script (mysql_system_tables_data.sql),
        although it was checking for the presence of this script.
        Fixed by re-enabling the lookup for this file and replaying it at bootstrap
        time. Note that on the Unixes "SELECT @@hostname" does return a fully qualified
        name, whereas on Windows it returns only a hostname.
        So by default we're filtering records in the mysql.user table until we ensure
        this is fixed.
      
      The change was coded in 5.5 by Georgi Kodinov <Georgi.Kodinov@Oracle.com>
      c0a1b2c8