1. 26 Dec, 2012 4 commits
  2. 24 Dec, 2012 4 commits
    • Annamalai Gurusami's avatar
      bf21d8a0
    • Annamalai Gurusami's avatar
      Fixing a pb2 issue. There is some difference in the output in my local... · d1dcbfd2
      Annamalai Gurusami authored
      Fixing a pb2 issue.  There is some difference in the output in my local machine and pb2 machines in the explain output.  
      d1dcbfd2
    • Chaithra Gopalareddy's avatar
      Merge from 5.1 · 531dbab9
      Chaithra Gopalareddy authored
      531dbab9
    • Chaithra Gopalareddy's avatar
      Bug#11757005: UNION CONVERTS UNSIGNED MEDIUMINT AND BIGINT · adc973d5
      Chaithra Gopalareddy authored
                    TO SIGNED
      Problem:
      When we are joining types (of fields) in case of a union, we usually
      upgrade the datatypes to the largest present in the query.
      In case of mediumint, it is not happening.
      Analysis:
      When joined with types LONG and LONGLONG, mediumint should get
      upgraded to LONG and LONGLONG respectively.
      W.r.t the given query, constant '1' will be created as a LONGLONG
      internally and SIGNED flag is enabled. As a result, while combining
      types for the field, LONGLONG along with MEDIUMINT gets converted
      to LONG first. LONG with MEDIUMINT(of the third select) gets converted
      to MEDIUMINT. SIGNED FLAG would be that of the first field's.
      As a result, the final result would be SIGNED MEDIUMINT.
      Fix:
      While joining types, MEDIUMINT with LONGLONG and MEDIUMINT with LONG
      is converted to LONGLONG and LONG respectively. Also, made some 
      changes for FLOAT and DOUBLE.
      adc973d5
  3. 21 Dec, 2012 4 commits
    • Tor Didriksen's avatar
      merge 5.1 => 5.5 · a8bcaf49
      Tor Didriksen authored
      a8bcaf49
    • Roy Lyseng's avatar
      Bug#15972635: Incorrect results returned in 32 table join with HAVING · 8b1d1cf5
      Roy Lyseng authored
      The problem is a shift operation that is not 64-bit safe.
      The consequence is that used tables information for a join with 32 tables
      or more will be incorrect.
      
      Fixed by adding a type cast in Item_sum::update_used_tables().
      
      Also used the opportunity to fix some other potential bugs by adding an
      explicit type-cast to an integer in a left-shift operation.
      Some of them were quite harmless, but was fixed in order to get the same
      signed-ness as the other operand of the operation it was used in.
      
      sql/item_cmpfunc.cc
        Adjusted signed-ness for some integers in left-shift.
      
      sql/item_subselect.cc
        Added type-cast to nesting_map (which is a 32/64 bit type, so
        potential bug for deeply nested queries).
      
      sql/item_sum.cc
        Added type-cast to nesting_map (32/64-bit type) and table_map
        (64-bit type).
      
      sql/opt_range.cc
        Added type-cast to ulonglong (which is a 64-bit type).
      
      sql/sql_base.cc
        Added type-cast to nesting_map (which is a 32/64-bit type).
      
      sql/sql_select.cc
        Added type-cast to nesting_map (32/64-bit type) and key_part_map
        (64-bit type).
      
      sql/strfunc.cc
        Changed type-cast from longlong to ulonglong, to preserve signed-ness.
      8b1d1cf5
    • prabakaran thirumalai's avatar
      Bug#14627287 THREAD CACHE - BYPASSES PRIVILEGES · 7817b813
      prabakaran thirumalai authored
      merge from 5.1
      7817b813
    • prabakaran thirumalai's avatar
      Bug#14627287 THREAD CACHE - BYPASSES PRIVILEGES · 0d5d4e5d
      prabakaran thirumalai authored
      Analysis:
      When thread cache is enabled, it does not properly initialize
      thd->start_utime when a thread is picked from the thread cache.
      This breaks the quota management mechanism. 
      THD::time_out_user_resource_limits() resets 
      m_user_connect->conn_per_hour to 0 based on thd->start_utime
      
      Fix:
      Initialize start_utime when cached thread is reused.
      
      Notes:
      Enabled back tests which were disabled because of this issue.
      0d5d4e5d
  4. 20 Dec, 2012 3 commits
    • Annamalai Gurusami's avatar
      Bug #13819630 ARCHIVE TABLE WITH 1000+ PARTITIONS CRASHES SERVER · 090ea1f8
      Annamalai Gurusami authored
      ON "DROP TABLE"
      
      In the function ha_archive::write_row(), there is an error code path
      that exits the function without releasing the mutex that was acquired
      earlier.  
      
      rb#1743 approved by ramil.
      090ea1f8
    • Tor Didriksen's avatar
      Bug#16027468 ADDRESSSANITIZER BUG IN MYSQLTEST · 0b83ecb6
      Tor Didriksen authored
      DBUG_ENTER and DBUG_LEAVE must *always* match,
      otherwise all subsequent DBUG_ENTER calls will 
      be poking into undefined stack frames.
      0b83ecb6
    • Annamalai Gurusami's avatar
      Bug #14556349 RENAME OF COMPRESSED TABLE AND INSERT BUFFER MERGE CAUSE · 7b145111
      Annamalai Gurusami authored
      HANG
      
      Problem Statement:
      
      When the operation RENAME TABLE is about rename the tablespace of the
      table, it will stop all i/o operations on the tablespace temporarily.
      For this the fil_space_t::stop_ios member is used.
      
      Once the fil_space_t::stop_ios member is set to TRUE in the RENAME
      TABLE operation, it is expected that no new i/o operation will be done
      on the tablespace and all pending i/o operation can be completed on
      the tablespace.
      
      If the pending i/o operations initiate any new i/o operations then
      there will be deadlock.  The RENAME TABLE operation will be waiting
      for pending i/o on the tablespace to be completed, and the pending i/o
      operations will be waiting on the RENAME TABLE operation to set the
      file_space_t::stop_ios flag to be set to FALSE.
      
      But in the given scenario the pending i/o operations did not initiate
      new i/o.  But they where still unnecessarily checking the
      fil_space_t::stop_ios flag.  This resulted in deadlock.
      
      Solution:
      
      I noticed that this deadlock happens in fil_space_get_size() and
      fil_space_get_zip_size() in the i/o threads.  These functions check
      the stop_ios flag even when no i/o will be initiated.  I modified
      these functions to ensure that they check the stop_ios flag only when
      they will be initiating an i/o operation.  This solves the problem.
      
      rb://1635 (mysql-5.5)
      rb://1660 (mysql-trunk) approved by Inaam, Jimmy, and ima.
      7b145111
  5. 19 Dec, 2012 2 commits
  6. 18 Dec, 2012 6 commits
    • Vasil Dimov's avatar
      Merge mysql-5.1 -> mysql-5.5 · 20cefd5f
      Vasil Dimov authored
      20cefd5f
    • Vasil Dimov's avatar
      Fix Bug#16000909 MEMORY LEAK, MYSQL_INPLACE_ALTER_TABLE · 17c71588
      Vasil Dimov authored
      This is a followup to the fix of
      Bug#14628410 ASSERTION `! IS_SET()' FAILED IN DIAGNOSTICS_AREA::SET_OK_STATUS
      (satya.bodapati@oracle.com-20121213132316-5joz4phltx9yhjs7)
      
      In innobase_mysql_tmpfile(): allocate/open the file after
      the return(-1); statement.
      17c71588
    • Ahmad Abdullateef's avatar
      BUG#14727815 - CRASH IN PTHREAD_RWLOCK_WRLOCK/SRW_UNLOCK · bac6523d
      Ahmad Abdullateef authored
                                   IN QUERY CACHE CODE
      
      DESCRIPTION:
      MySQL Server crashes sporadically when Query Caching is on and
      the server has high contention among clients. 
      
      
      ANALYSIS :
      
      Scenario 1:
      In Query_cache::move_by_type() when handling RESULT or its related blocks,
      Write Lock is acquired on its parent Query block. However the next and prev
      pointers are cached in local variables before lock acquisition. In an extremely
      high contention scenario there exists a possibility that
      Query_cache::append_result_data() is operating on the same query block
      and as a consequence might append a new Result block to the end of Result
      blocks Linked List of the Query. This would manipulate the next, prev pointers
      of the Block being processed in move_by_type(), however the local pointers
      still point to previous nodes there by causing Data Corruption leading to crash.
      
      Scenario 2:
      In Windows SDK "BOOL" is typedefed as "int" and BOOLEAN is typedefed as
      "usigned char". The function pointer definition "srw_bool_func" mistakenly uses 
      BOOL instead of BOOLEAN thereby virtually making the function 
      my_TryAcquireSRWLockExclusive() always succeed because only the LSB of EAX
      has the actual result of the call, however due to type mismatch all bytes of EAX
      are used for evaluation. Again during high contention scenarios in 
      Query_cache::free_old_query() calls try_lock_writing() on a Query, this call 
      always succeeds and the query is freed, even though it is used by some other
      thread, in this case Query_cache::send_result_to_client() was using it and the
      code causes a crash because it accessed free or reallocated memory.
      
      FIX :
      
      Scenario 1:
      The next, prev pointers are now accessed only after Lock acquisition in 
      Query_cache::move_by_type().
      
      Scenario 2:
      In the definition of "srw_bool_func" BOOL has been replaced with "BOOLEAN"
      bac6523d
    • Ahmad Abdullateef's avatar
      BUG#14727815 - CRASH IN PTHREAD_RWLOCK_WRLOCK/SRW_UNLOCK · 6d82d9c9
      Ahmad Abdullateef authored
                                   IN QUERY CACHE CODE
      
      DESCRIPTION:
      MySQL Server crashes sporadically when Query Caching is on and
      the server has high contention among clients. 
      
      
      ANALYSIS :
      
      Scenario 1:
      In Query_cache::move_by_type() when handling RESULT or its related blocks,
      Write Lock is acquired on its parent Query block. However the next and prev
      pointers are cached in local variables before lock acquisition. In an extremely
      high contention scenario there exists a possibility that
      Query_cache::append_result_data() is operating on the same query block
      and as a consequence might append a new Result block to the end of Result
      blocks Linked List of the Query. This would manipulate the next, prev pointers
      of the Block being processed in move_by_type(), however the local pointers
      still point to previous nodes there by causing Data Corruption leading to crash.
      
      FIX :
      
      Scenario 1:
      The next, prev pointers are now accessed only after Lock acquisition in 
      Query_cache::move_by_type().
      6d82d9c9
    • Vasil Dimov's avatar
      Merge mysql-5.1 -> mysql-5.5 · 328430b4
      Vasil Dimov authored
      328430b4
    • Vasil Dimov's avatar
      Fix Bug#13463493 INNODB PLUGIN WERE CHANGED, BUT STILL USE THE · 3cdef32c
      Vasil Dimov authored
      SAME VERSION NUMBER 1.0.17
      
      Now that InnoDB/InnoDB Plugin is no longer separately developed and
      distributed from the MySQL server it does not need its own version number.
      Thus use the MySQL version instead.
      
      "Removing" the version altogether is not feasible because the config
      variable 'innodb_version' cannot be removed in GA branches.
      
      Reviewed by:	Marko (rb#1751)
      3cdef32c
  7. 14 Dec, 2012 2 commits
  8. 13 Dec, 2012 3 commits
    • Ravinder Thakur's avatar
      bug#11761752: DO NOT ALLOW USE OF ALTERNATE DATA STREAMS ON NTFS FILESYSTEM. · 92582232
      Ravinder Thakur authored
      File names with colon are being disallowed because of the Alternate Data 
      Stream (ADS) feature of NTFS that could be misused. ADS allows data to be 
      written to alternate streams of a normal file. The data in alternate 
      streams cannot be seen by normal tools on Windows (explorer, cmd.exe). As 
      a result someone can use this feature to hide large amount of data in 
      alternate streams and admins will have no easy way of figuring out the 
      files that are using that disk space. The fix also disallows ADS in the 
      scenarios where file name is passed as some dynamic variable.
      
      An important thing about the fix is that it DOES NOT disallow ADS file 
      names if they are not dynamic (i.e. if the file is created by using some 
      option that needs local access to the MySQL server, for example error log
      file). The reasoning is that if some MySQL option related to files 
      requires access to the local machine (it is not dynamic), then user can very 
      well create data in ADS by some other means. This fixes only those scenarios 
      which can allow users to create data in ADS over the wire.
      
      File names with colon are being disallowed only on Windows. UNIX 
      (Linux in particular) supports NTFS, but it will not be a common 
      scenario for someone to configure a NTFS file system to store MySQL 
      data on Linux.
      
      Changes in file bug11761752-master.opt are needed due to 
      bug number 15937938.
      92582232
    • Satya Bodapati's avatar
      Bug#14628410 - ASSERTION `! IS_SET()' FAILED IN DIAGNOSTICS_AREA::SET_OK_STATUS · a01e70c2
      Satya Bodapati authored
      The error code returned from Merge file/Temp file creation functions are
      ignored.
      
      Use the return codes of the row_merge_file_create() and innobase_mysql_tmpfile()
      to return the error to caller if file creation fails.
      
      Approved by Marko. rb#1618
      a01e70c2
    • Harin Vadodaria's avatar
      Bug#15965288: BUFFER OVERFLOW IN YASSL FUNCTION · 69689fa4
      Harin Vadodaria authored
                    DOPROCESSREPLY()
      
      Description: Function DoProcessReply() calls function
                   decrypt_message() in a while loop without
                   performing a check on available buffer
                   space. This can cause buffer overflow and
                   crash the server. This patch is fix provided
                   by Sawtooth to resolve the issue.
      69689fa4
  9. 12 Dec, 2012 1 commit
  10. 11 Dec, 2012 3 commits
    • Dmitry Lenev's avatar
      Bug #15954872 "MAKE MDL SUBSYSTEM AND TABLE DEFINITION CACHE · 7ff0d02d
      Dmitry Lenev authored
      ROBUST AGAINST BUGS IN CALLERS".
      
      Both MDL subsystems and Table Definition Cache code assume 
      that callers ensure that names of objects passed to them are 
      not longer than NAME_LEN bytes. Unfortunately due to bugs in 
      callers this assumption might be broken in some cases. As
      result we get nasty bugs causing buffer overruns when we
      construct MDL key or TDC key from object names.
      
      This patch makes TDC code more robust against such bugs by 
      ensuring that we always checking size of result buffer when
      constructing TDC keys. This doesn't free its callers from 
      ensuring that both db and table names are shorter than 
      NAME_LEN bytes. But at least this steps prevents buffer 
      overruns in case of bug in caller, replacing them with less 
      harmful behavior.
      
      This is 5.1-only version of patch.
      
      This patch introduces new version of create_table_def_key()
      helper function which constructs TDC key without risk of
      result buffer overrun. Places in code that construct TDC keys 
      were changed to use this function.
      
      Also changed rm_temporary_table() and open_new_frm() functions
      to avoid use of "unsafe" strmov() and strxmov() functions and 
      use safer strnxmov() instead.
      7ff0d02d
    • sayantan.dutta@oracle.com's avatar
    • Annamalai Gurusami's avatar
      Bug #14200010 NEWLY CREATED TABLE DOESN'T ALLOW FOR LOOSE INDEX SCANS · 295ad743
      Annamalai Gurusami authored
      Problem:
      
      Before the ALTER TABLE statement, the array
      dict_index_t::stat_n_diff_key_vals had proper values calculated
      and updated.  But after the ALTER TABLE statement, all the values
      of this array is 0.  
      
      Because of this statistics returned by innodb_rec_per_key() is
      different before and after the ALTER TABLE statement. Running the
      ANALYZE TABLE command populates the statistics correctly.
      
      Solution:
      
      After ALTER TABLE statement, set the flag dict_table_t::stat_initialized
      correctly so that the table statistics will be recalculated properly when
      the table is next loaded.  But note that we still don't choose the loose
      index scans.  This fix only ensures that an ALTER TABLE does not change
      the optimizer plan.
      
      rb://1639 approved by Marko and Jimmy.
      295ad743
  11. 10 Dec, 2012 1 commit
  12. 17 Dec, 2012 1 commit
  13. 14 Dec, 2012 2 commits
  14. 13 Dec, 2012 4 commits