1. 13 Dec, 2012 4 commits
  2. 12 Dec, 2012 3 commits
  3. 11 Dec, 2012 7 commits
    • Dmitry Lenev's avatar
      Bug #15954872 "MAKE MDL SUBSYSTEM AND TABLE DEFINITION CACHE · 1874591d
      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 MDL and TDC code more robust against such
      bugs by ensuring that we always checking size of result
      buffer when constructing MDL and 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 these steps
      prevents buffer overruns in case of bug in caller, replacing
      them with less harmful behavior.
      
      This is 5.5-only version of patch.
      
      Changed code of MDL_key::mdl_key_init() to take into account
      size of buffer for the key.
      
      Introduced 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.
      1874591d
    • 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
      upmerge 14737171 5.1 => 5.5 · 2c2ad47a
      sayantan.dutta@oracle.com authored
      2c2ad47a
    • sayantan.dutta@oracle.com's avatar
    • Joerg Bruehe's avatar
      Merge ULN RPM stuff to main branch. · ca8d8ca7
      Joerg Bruehe authored
      ca8d8ca7
    • Annamalai Gurusami's avatar
      ffa4c37c
    • 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
  4. 10 Dec, 2012 1 commit
    • Joerg Bruehe's avatar
      RPMs for ULN do not build in MySQL 5.6: Patches + libmysqld.so · 66f1e55b
      Joerg Bruehe authored
      Bug #15972480
      
      This is the change for 5.5:
          a cleanup in the way "libmysqld.so" is created.
      (Patches were adapted for 5.5 previously.)
      
      Originally, the ".so" was created by taking all modules in
      "libmysqld.a", after removing some few which caused unresolved
      references.
      This is no good idea, rather "ld" should be used to follow all
      references from some few start modules.
      
      At the same time, the ".so" version needed to be corrected:
      The original "0.0.1" is both wrong and risky.
      Rather, the server version is used to identify the ".so" file,
      but for linkage the first two levels are sufficient (so upgrades
      are possible without re-building the embedded application).
      66f1e55b
  5. 09 Dec, 2012 3 commits
  6. 07 Dec, 2012 2 commits
  7. 06 Dec, 2012 2 commits
    • Harin Vadodaria's avatar
      Bug#15912213: BUFFER OVERFLOW IN ACL_GET() · cf231cab
      Harin Vadodaria authored
                  
      Description: A very large database name causes buffer
                   overflow in functions acl_get() and
                   check_grant_db() in sql_acl.cc. It happens
                   due to an unguarded string copy operation.
                   This puts required sanity checks before
                   copying db string to destination buffer.
      cf231cab
    • Dmitry Shulga's avatar
      This patch fixes bug#14729757 - MY_HASH_SEARCH(&XID_CACHE, · 0109a65c
      Dmitry Shulga authored
                                      XID_STATE->XID.KEY(),
                                      XID_STATE->XID.KEY_LENGTH())==0
        
      This bug is a regression of bug#11759534 - 51855: RACE CONDITION
                                                 IN XA START.
        
      The reason for regression is that the changes that fixes the original
      bug wasn't merged from mysql-5.1 into mysql-5.5 and mysql-trunk.
      Only null-merge was done for the patch changeset.
        
      To incorporate lost changes the manual merge have been done.
        
      Additionally the call of trans_rolback() was added into trans_xa_start()
      in case if xid_cache_insert is failed() after transaction has been started.
      If we don't call trans_rollback() we would never reset the flag
      SERVER_STATUS_IN_TRANS in THD::server_status and therefore all subsequent
      attempts to execute XA START in the connection where the error was occurred
      will be failed since thd->in_active_multi_stmt_transaction() will return
      the true every time when trans_xa_start is called.
        
      The latest changes were absent in patch for mysql-5.1
      0109a65c
  8. 05 Dec, 2012 8 commits
    • Gleb Shchepa's avatar
      Bug #15948123: SERVER WORKS INCORRECT WITH LONG TABLE ALIASES · 38457c1a
      Gleb Shchepa authored
      Post-push cleanup: removal of unneeded assertions.
      38457c1a
    • Dmitry Lenev's avatar
      c285b146
    • Dmitry Lenev's avatar
      Bug #15954896 "SP, MULTI-TABLE DELETE AND LONG ALIAS". · 111646ab
      Dmitry Lenev authored
      Using too long table aliases in stored routines might
      have caused server crashes.
      
      Code in sp_head::merge_table_list() which is responsible 
      for collecting information about tables used in stored
      routine was not aware of the fact that table alias might
      have arbitrary length. I.e. it assumed that table alias
      can't be longer than NAME_LEN bytes and allocated buffer
      for a key identifying table accordingly.
      
      This patch fixes the issue by ensuring that we use
      dynamically allocated buffer for table key when table
      alias is too long. By default stack based buffer is used
      in which NAME_LEN bytes are reserved for table alias.
      111646ab
    • mysql-builder@oracle.com's avatar
      No commit message · bde28da6
      mysql-builder@oracle.com authored
      No commit message
      bde28da6
    • Bjorn Munch's avatar
      3c1852e2
    • Gleb Shchepa's avatar
      Bug #15948123: SERVER WORKS INCORRECT WITH LONG TABLE ALIASES · 9c59f5a5
      Gleb Shchepa authored
      Code in MDL subsystem assumes that identifiers of objects can't
      be longer than NAME_LEN characters. This assumption was broken
      when one tried to construct MDL_key based on table alias, which
      can have arbitrary length. Since MDL_key's (and MDL locks) are
      not really used for table aliases this patch changes code to
      not initialize MDL_key object for table list element representing
      aliases.
      9c59f5a5
    • Shivji Kumar Jha's avatar
      611b3c46
    • Shivji Kumar Jha's avatar
      BUG#12359942 - REPLICATION TEST FROM ENGINE SUITE RPL_ROW_UNTIL TIMES OUT · 3ed7eb3a
      Shivji Kumar Jha authored
            
      === Problem ===
            
      The test is dependent on binlog positions and checks
      to see if the command 'START SLAVE' functions correctly
      with the 'UNTIL' clause added to it. The 'UNTIL' clause
      is added to specify that the slave should start and run
      until the SQL thread reaches a given point in the master
      binary log or in the slave relay log.
            
      The test uses hard coded values for MASTER_LOG_POS and
      RELAY_LOG_POS, instead of extracting it using
      query_get_value() function. There is a test
      'rpl.rpl_row_until' which does the similar thing but uses 
      query_get_value() function to set the values of
      MASTER_LOG_POS/ RELAY_LOG_POS. To be precise,
      rpl.rpl_row_until is a modified version of
      engines/func.rpl_row_until.test.
            
      The use of hard coded values may lead the slave to stop at a position
      which may differ from the expected position in the binlog file,
      an example being the failure of engines/funcs.rpl_row_until in 
      mysql-5.1 given as: 
      "query 'select * from t2' failed. Table 'test.t2' doesn't exist".
      In this case, the slave actually ran a couple of extra commands
      as a result of which the slave first deleted the table and then
      ran a select query on table, leading to the above mentioned failure.
            
      === Fix ===
          
      1) Fixed the code for failure seen in rpl.rpl_row_until.
         This test was also failing although the symptoms of
         failure were different.
      2) Copied the contents from rpl.rpl_row_until into
         into engines/funcs.rpl.rpl_row_until.
      3) Updated engines/funcs.rpl_row_until.result accordingly.
      3ed7eb3a
  9. 04 Dec, 2012 3 commits
    • Pedro Gomes's avatar
      Bug#13545447 RPL_ROTATE_LOGS FAILS DUE TO CONCURRENCY ISSUES IN REP. CODE · ee94a9ca
      Pedro Gomes authored
      RPL_ROTATE_LOGS has been failing sporadically in what seems a
      problem related to routines that update the coordinates. However,
      the test lacks proper assert statments and because of this the
      debug information upon failure simply points to the content
      mismatch between the test and the result file.
      
      Not as a solution, but as a improvement to the test to better
      debug this failure, new assert statments were added to the test.
      
      @rpl_rotate_logs.test
        Added new assert statments reducing the
        dependency on the result file.
      
      @rpl_rotate_logs.result
        Added new content to the result file to
        match the test changes
      ee94a9ca
    • Manish Kumar's avatar
      BUG#13812374 - RPL.RPL_REPORT_PORT FAILS OCCASIONALLY ON PB2 · f0dcda60
      Manish Kumar authored
      Problem: The problem with the test is that the slave returns 
               from start_slave.inc call too early before the list
               is actually actualised. This caused the slave stale 
               data to be reported.
      
      Fix: Added a wait in the test till the slave's IO status is 
           changed to "Waiting for master to send event" which 
           which ensures the list is correctly updated.
      f0dcda60
    • Yasufumi Kinoshita's avatar
      UNIV_DEBUG build of some environments needs · 8d374dd3
      Yasufumi Kinoshita authored
      #include "read0read.h"
      for srv0srv.c and trx0rec.c.
      This is only for mysql-5.5
      8d374dd3
  10. 01 Dec, 2012 5 commits
  11. 30 Nov, 2012 2 commits