1. 05 Dec, 2012 3 commits
    • 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
  2. 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
  3. 01 Dec, 2012 5 commits
  4. 30 Nov, 2012 4 commits
    • Mattias Jonsson's avatar
      bug#14589559: ASSERTION `FILE_ENTRY_BUF[2] == 0' FAILED · fbe1315b
      Mattias Jonsson authored
                                 IN DEACTIVATE_DDL_LOG_ENTRY
      
      Update of comments according to reviewers request.
      fbe1315b
    • Inaam Rana's avatar
      merge from 5.1 · d1923690
      Inaam Rana authored
      d1923690
    • Inaam Rana's avatar
      Reverting fix for bug#14329288 · 672a6496
      Inaam Rana authored
      revid that is being reverted: marko.makela@oracle.com-20121128070024-hb56t41limja8edz
      672a6496
    • Shivji Kumar Jha's avatar
      BUG#12359942 - REPLICATION TEST FROM ENGINE SUITE RPL_ROW_UNTIL TIMES OUT · daeda052
      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.
      daeda052
  5. 29 Nov, 2012 4 commits
    • Tor Didriksen's avatar
      Bug#11754279 SIGNIFICANT INACCURACY IN DECIMAL MULTIPLICATION CALCULATIONS · b125abec
      Tor Didriksen authored
          frac is the number of decimal digits after the point
      For each multiplication in the expression, decimal_mul() does this:
        to->frac= from1->frac + from2->frac;              /* store size in digits */
      which will eventually overflow.
      The code for handling the overflow, will truncate the two digits in "1.75" to "1"
      
      Solution:
      Truncate to 31 significant fractional digits, when doing decimal multiplication.
      b125abec
    • Venkatesh Duggirala's avatar
      BUG#15888454: SLAVE CRASHES WHEN DML REQUIRES CONVERSION & TABLE HAS · d68cba34
      Venkatesh Duggirala authored
      LESS COLUMNS THAN MASTER
      
      Problem:
      ========
      If DML operation requires a converstion at slave and if slave contains
      less number of columns than master, slave is crashing.
      
      Fix:
      ====
      When Slave applies any DML operation, it sees if any of the columns 
      requires conversion. If yes, it creates conversion table. 
      While creating the coversion table, it should look into the actual number 
      of columns required to create the table instead of getting the number
      of columns from Master (size()). Columns would have dropped or added
      at Slave. So the value should be min(columns@master, columns@slave)
      d68cba34
    • Harin Vadodaria's avatar
      Bug#15912213: BUFFER OVERFLOW IN ACL_GET() · 6a2f2338
      Harin Vadodaria authored
      Description: Null merge.
      6a2f2338
    • Harin Vadodaria's avatar
      Bug#15912213: BUFFER OVERFLOW IN ACL_GET() · bc6287a3
      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.
      bc6287a3
  6. 28 Nov, 2012 5 commits
  7. 26 Nov, 2012 6 commits
  8. 21 Nov, 2012 2 commits
  9. 20 Nov, 2012 4 commits
    • Nuno Carvalho's avatar
      BUG#15891524: RLI_FAKE MODE IS NOT UNSET AFTER BINLOG REPLAY · d0f5427c
      Nuno Carvalho authored
      When a binlog is replayed into a server, e.g.:
        $ mysqlbinlog binlog.000001 | mysql
      it sets a pseudo slave mode on the client connection in order to server
      be able to read binlog events, there is, a format description event is
      needed to correctly read following events.
      Also this pseudo slave mode applies to the current connection
      replication rules that are needed to correctly apply binlog events.
      
      If a binlog dump is sourced on a connection, this pseudo slave mode will
      remains after it, what will apply unexpected rules from customer
      perspective to following commands.
      
      Added a new SET statement to binlog dump that will unset pseudo slave
      mode at the end of dump file.
      d0f5427c
    • sayantan.dutta@oracle.com's avatar
    • Vamsikrishna Bhagi's avatar
      Bug#14463669 FAILURE TO CORRECTLY PARSE ROUTINES IN · e4a6dbd3
      Vamsikrishna Bhagi authored
                         MYSQLDUMP OUTPUT
            
            A patch is pushed on this bug. A result mismatch
            occured for the test main.ddl_i18n_utf8 in
            x86_64 gcov build of linux in pb2. This commit is
            to modify ddl_i18n_utf8.result to match the
            changes made for the bug.
      e4a6dbd3
    • Vamsikrishna Bhagi's avatar
      Bug#14463669 FAILURE TO CORRECTLY PARSE ROUTINES IN · c0157d16
      Vamsikrishna Bhagi authored
                   MYSQLDUMP OUTPUT
      
      A patch is pushed on this bug. A result mismatch
      occured for the test main.ddl_i18n_koi8r in
      x86_64 gcov build of linux in pb2. This commit is
      to modify ddl_i18n_koi8r.result to match the
      changes made for the bug.
      c0157d16
  10. 19 Nov, 2012 2 commits
    • Vamsikrishna Bhagi's avatar
      Bug#14463669 FAILURE TO CORRECTLY PARSE ROUTINES IN · f1e9b721
      Vamsikrishna Bhagi authored
                   MYSQLDUMP OUTPUT
      
      Problem: mysqldump when used with option --routines, dumps
               all the routines of the specified database into
               output. The statements in this output are written
               in such a way that they are version safe using C
               style version commenting (of the format
               /*!<version num> <sql statement>*/). If a semicolon
               is present right before closing of the comment in
               dump output, it results in a syntax error while
               importing.
      
      
      Solution: Version comments for dumped routines are
                specifically to protect the ones older than 5.0.
                When the import is done on 5.0 or later versions,
                entire create statement gets executed as all the
                check conditions at the beginning of the comments
                are cleared. Since the trade off is between the
                performance of newer versions which are more in
                use and protection of very old versions which are
                no longer supported, it is proposed that these
                comments be removed altogether to maintain
                stability of the versions supported.
      f1e9b721
    • Satya Bodapati's avatar
      Bug#14147491 - INFINITE LOOP WHEN OPENING A CORRUPTED TABLE · 64e61199
      Satya Bodapati authored
      This bug is fixed by Bug#14251529. Only testcase from the 
      contribution is used.
      64e61199
  11. 16 Nov, 2012 2 commits