1. 28 Aug, 2009 2 commits
  2. 27 Aug, 2009 6 commits
    • Alfranio Correia's avatar
      BUG#46861 Auto-closing of temporary tables broken by replicate-rewrite-db · ea06bbd2
      Alfranio Correia authored
      When a connection is dropped any remaining temporary table is also automatically
      dropped and the SQL statement of this operation is written to the binary log in
      order to drop such tables on the slave and keep the slave in sync. Specifically,
      the current code base creates the following type of statement:
      DROP /*!40005 TEMPORARY */ TABLE IF EXISTS `db`.`table`;
      
      Unfortunately, appending the database to the table name in this manner circumvents
      the replicate-rewrite-db option (and any options that check the current database).
      To solve the issue, we started writing the statement to the binary as follows:
      use `db`; DROP /*!40005 TEMPORARY */ TABLE IF EXISTS `table`;
      ea06bbd2
    • Alfranio Correia's avatar
      BUG#46864 Incorrect update of InnoDB table on slave when using trigger with myisam table · 354f5f7b
      Alfranio Correia authored
      Slave does not correctly handle "expected errors" leading to inconsistencies
      between the mater and slave. Specifically, when a statement changes both
      transactional and non-transactional tables, the transactional changes are
      automatically rolled back on the master but the slave ignores the error and
      does not roll them back thus leading to inconsistencies.
            
      To fix the problem, we automatically roll back a statement that fails on
      the slave but note that the transaction is not rolled back unless a "rollback"
      command is in the relay log file.
      
      mysql-test/extra/rpl_tests/rpl_mixing_engines.test:
        Enabled item 13.e which was disabled because of the bug fixed by the
        current and removed item 14 which was introduced by mistake.
      354f5f7b
    • Sergey Glukhov's avatar
      5.0-bugteam->5.1-bugteam merge · 51f4ccfa
      Sergey Glukhov authored
      51f4ccfa
    • Sergey Glukhov's avatar
      Bug#46184 Crash, SELECT ... FROM derived table procedure analyze · 367c14b8
      Sergey Glukhov authored
      The crash happens because select_union object is used as result set
      for queries which have derived tables.
      select_union use temporary table as data storage and if
      fields count exceeds 10(count of values for procedure ANALYSE())
      then we get a crash on fill_record() function.
      
      
      mysql-test/r/analyse.result:
        test result
      mysql-test/r/subselect.result:
        result fix
      mysql-test/t/analyse.test:
        test case
      mysql-test/t/subselect.test:
        test fix
      sql/sql_yacc.yy:
        The crash happens because select_union object is used as result set
        for queries which have derived tables.
        select_union use temporary table as data storage and if
        fields count exceeds 10(count of values for procedure ANALYSE())
        then we get a crash on fill_record() function.
      367c14b8
    • Alfranio Correia's avatar
      Post-fix for BUG#28976. · 1759f9ec
      Alfranio Correia authored
      Updated main.mysqlbinlog_row_trans's result file as 
      TRUNCATE statements are wrapped in BEGIN...COMMIT.
      1759f9ec
    • Georgi Kodinov's avatar
      merged 5.0-bugteam -> 5.1-bugteam · f10e85f5
      Georgi Kodinov authored
      f10e85f5
  3. 26 Aug, 2009 1 commit
    • Alfranio Correia's avatar
      BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect · 6c2b3251
      Alfranio Correia authored
      binlog
      
      Mixing transactional (T) and non-transactional (N) tables on behalf of a
      transaction may lead to inconsistencies among masters and slaves in STATEMENT
      mode. The problem stems from the fact that although modifications done to
      non-transactional tables on behalf of a transaction become immediately visible
      to other connections they do not immediately get to the binary log and therefore
      consistency is broken. Although there may be issues in mixing T and M tables in
      STATEMENT mode, there are safe combinations that clients find useful.
      
      In this bug, we fix the following issue. Mixing N and T tables in multi-level
      (e.g. a statement that fires a trigger) or multi-table table statements (e.g.
      update t1, t2...) were not handled correctly. In such cases, it was not possible
      to distinguish when a T table was updated if the sequence of changes was N and T.
      In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect
      that both a N and T tables were changed. To circumvent this issue, we check if an
      engine is registered in the handler's list and changed something which means that
      a T table was modified.
      
      Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or
      ROW modes completely safe.
      
      mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result:
        Truncate statement is wrapped in BEGIN/COMMIT.
      mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result:
        Truncate statement is wrapped in BEGIN/COMMIT.
      6c2b3251
  4. 24 Aug, 2009 4 commits
    • Davi Arnaut's avatar
      Bug#45261: Crash, stored procedure + decimal · fc394595
      Davi Arnaut authored
      The problem was that creating a DECIMAL column from a decimal
      value could lead to a failed assertion as decimal values can
      have a higher precision than those attached to a table. The
      assert could be triggered by creating a table from a decimal
      with a large (> 30) scale. Also, there was a problem in
      calculating the number of digits in the integral and fractional
      parts if both exceeded the maximum number of digits permitted
      by the new decimal type.
      
      The solution is to ensure that truncation procedure is executed
      when deducing a DECIMAL column from a decimal value of higher
      precision. If the integer part is equal to or bigger than the
      maximum precision for the DECIMAL type (65), the integer part
      is truncated to fit and the fractional becomes zero. Otherwise,
      the fractional part is truncated to fit into the space left
      after the integer part is copied.
      
      This patch borrows code and ideas from Martin Hansson's patch.
      
      mysql-test/r/type_newdecimal.result:
        Add test case result for Bug#45261. Also, update test case to
        reflect that an additive operation increases the precision of
        the resulting type by 1.
      mysql-test/t/type_newdecimal.test:
        Add test case for Bug#45261
      sql/field.cc:
        Added DBUG_ASSERT to ensure object's invariant is maintained.
        Implement method to create a field to hold a decimal value
        from an item.
      sql/field.h:
        Explain member variable. Add method to create a new decimal field.
      sql/item.cc:
        The precision should only be capped when storing the value
        on a table. Also, this makes it impossible to calculate the
        integer part if Item::decimals (the scale) is larger than the
        precision.
      sql/item.h:
        Simplify calculation of integer part.
      sql/item_cmpfunc.cc:
        Do not limit the precision. It will be capped later.
      sql/item_func.cc:
        Use new method for allocating a new decimal field.
        Add a specialized method for retrieving the precision
        of a user variable item.
      sql/item_func.h:
        Add method to return the precision of a user variable.
      sql/item_sum.cc:
        Use new method for allocating a new decimal field.
      sql/my_decimal.h:
        The integer part could be improperly calculated for a decimal
        with 31 digits in the fractional part.
      sql/sql_select.cc:
        Use new method which truncates the integer or decimal parts
        as needed.
      fc394595
    • Georgi Kodinov's avatar
      Bug #37044: Read overflow in opt_range.cc found during "make test" · 7492d622
      Georgi Kodinov authored
      The code was using a special global buffer for the value of IS NULL ranges.
      This was not always long enough to be copied by a regular memcpy. As a 
      result read buffer overflows may occur.
      Fixed by setting the null byte to 1 and setting the rest of the field disk image
      to NULL with a bzero (instead of relying on the buffer and memcpy()).
      7492d622
    • Alfranio Correia's avatar
    • Alfranio Correia's avatar
  5. 21 Aug, 2009 8 commits
    • Mattias Jonsson's avatar
      merge · 8b0ec014
      Mattias Jonsson authored
      8b0ec014
    • Mattias Jonsson's avatar
      Bug#46639: 1030 (HY000): Got error 124 from storage engine on · a4e832d6
      Mattias Jonsson authored
      INSERT ... SELECT ...
      
      Problem was that when bulk insert is used on an empty
      table/partition, it disables the indexes for better
      performance, but in this specific case it also tries
      to read from that partition using an index, which is
      not possible since it has been disabled.
      
      Solution was to allow index reads on disabled indexes
      if there are no records.
      
      Also reverted the patch for bug#38005, since that was a workaround
      in the partitioning engine instead of a fix in myisam.
      
      mysql-test/r/partition.result:
        Bug#46639: 1030 (HY000): Got error 124 from storage engine on
        INSERT ... SELECT ...
        
        updated result file
      mysql-test/t/partition.test:
        Bug#46639: 1030 (HY000): Got error 124 from storage engine on
        INSERT ... SELECT ...
        
        Added testcase
      sql/ha_partition.cc:
        Bug#46639: 1030 (HY000): Got error 124 from storage engine on
        INSERT ... SELECT ...
        
        reverted the patch for bug#38005, since that was a workaround
        around this problem, not needed after fixing it in myisam.
      storage/myisam/mi_search.c:
        Bug#46639: 1030 (HY000): Got error 124 from storage engine on
        INSERT ... SELECT ...
        
        Return HA_ERR_END_OF_FILE instead of HA_ERR_WRONG_INDEX
        when there are no rows.
      a4e832d6
    • Georgi Kodinov's avatar
      787a4940
    • Georgi Kodinov's avatar
      automerge · 8723e9d2
      Georgi Kodinov authored
      8723e9d2
    • Georgi Kodinov's avatar
      Revert of the fix for bug #46019. · 66ce3dee
      Georgi Kodinov authored
      66ce3dee
    • Martin Hansson's avatar
      Merge. · 8f75260b
      Martin Hansson authored
      8f75260b
    • Martin Hansson's avatar
      Merge. · b011f1ea
      Martin Hansson authored
      b011f1ea
    • Ramil Kalimullin's avatar
      Fix for bug #46456 [Ver->Prg]: HANDLER OPEN + TRUNCATE + DROP · fb9ba373
      Ramil Kalimullin authored
      (temporary) TABLE, crash
      
      Problem: if one has an open "HANDLER t1", further "TRUNCATE t1" 
      doesn't close the handler and leaves handler table hash in an 
      inconsistent state, that may lead to a server crash.
      
      Fix: TRUNCATE should implicitly close all open handlers.
      
      Doc. request: the fact should be described in the manual accordingly.
      
      
      mysql-test/r/handler_myisam.result:
        Fix for bug #46456 [Ver->Prg]: HANDLER OPEN + TRUNCATE + DROP
        (temporary) TABLE, crash
          - test result.
      mysql-test/t/handler_myisam.test:
        Fix for bug #46456 [Ver->Prg]: HANDLER OPEN + TRUNCATE + DROP
        (temporary) TABLE, crash
          - test case.
      sql/sql_delete.cc:
        Fix for bug #46456 [Ver->Prg]: HANDLER OPEN + TRUNCATE + DROP
         (temporary) TABLE, crash
          - remove all truncated tables from the HANDLER's hash.
      fb9ba373
  6. 20 Aug, 2009 3 commits
  7. 19 Aug, 2009 4 commits
    • Alfranio Correia's avatar
      BUG#45694 Deadlock in replicated statement is not retried · 40b9df39
      Alfranio Correia authored
      If the SQL Thread fails to execute an event due to a temporary error (e.g.
      ER_LOCK_DEADLOCK) and the option "--slave_transaction_retries" is set the SQL
      Thread should not be aborted and the transaction should be restarted from the
      beginning and re-executed.
      
      Unfortunately, a wrong interpretation of the THD::is_fatal_error was preventing
      this behavior. In a nutshell, "this variable is set to TRUE if an execution of a
      compound statement cannot continue. In particular, it is used to disable access
      to the CONTINUE or EXIT handlers of stored routines. So even temporary errors
      may have this variable set.
      
      To fix the bug, we have done what follows:
      
         DBUG_ENTER("has_temporary_error");
      
      -  if (thd->is_fatal_error)
      -    DBUG_RETURN(0);
      -
         DBUG_EXECUTE_IF("all_errors_are_temporary_errors",
                         if (thd->main_da.is_error())
                         {
      40b9df39
    • Georgi Kodinov's avatar
      Bug #46807: subselect test fails on PB-2 with a crash · 152943f3
      Georgi Kodinov authored
      The check for stack overflow was independent of the size of the 
      structure stored in the heap. 
      Fixed by adding sizeof(PARAM) to the requested free heap size.
      152943f3
    • Georgi Kodinov's avatar
      Bug #46019: ERROR 1356 When selecting from within another · 06655369
      Georgi Kodinov authored
      view that has Group By
            
      Table access rights checking function check_grant() assumed
      that no view is opened when it's called.
      This is not true with nested views where the inner view
      needs materialization. In this case the view is already 
      materialized when check_grant() is called for it.
      This caused check_grant() to not look for table level
      grants on the materialized view table.
      Fixed by checking if a view is already materialized and if 
      it is check table level grants using the original table name
      (not the ones of the materialized temp table).
      06655369
    • Georgi Kodinov's avatar
      40defb1d
  8. 17 Aug, 2009 3 commits
  9. 14 Aug, 2009 1 commit
  10. 13 Aug, 2009 5 commits
    • Davi Arnaut's avatar
      Merge from mysql-5.0-bugteam. · 1c2556ff
      Davi Arnaut authored
      1c2556ff
    • Davi Arnaut's avatar
      Bug#46013: rpl_extraColmaster_myisam fails on pb2 · 050c36c7
      Davi Arnaut authored
      Bug#45243: crash on win in sql thread clear_tables_to_lock() -> free()
      Bug#45242: crash on win in mysql_close() -> free()
      Bug#45238: rpl_slave_skip, rpl_change_master failed (lost connection) for STOP SLAVE
      Bug#46030: rpl_truncate_3innodb causes server crash on windows
      Bug#46014: rpl_stm_reset_slave crashes the server sporadically in pb2
      
      When killing a user session on the server, it's necessary to
      interrupt (notify) the thread associated with the session that
      the connection is being killed so that the thread is woken up
      if waiting for I/O. On a few platforms (Mac, Windows and HP-UX)
      where the SIGNAL_WITH_VIO_CLOSE flag is defined, this interruption
      procedure is to asynchronously close the underlying socket of
      the connection.
      
      In order to enable this schema, each connection serving thread
      registers its VIO (I/O interface) so that other threads can
      access it and close the connection. But only the owner thread of
      the VIO might delete it as to guarantee that other threads won't
      see freed memory (the thread unregisters the VIO before deleting
      it). A side note: closing the socket introduces a harmless race
      that might cause a thread attempt to read from a closed socket,
      but this is deemed acceptable.
      
      The problem is that this infrastructure was meant to only be used
      by server threads, but the slave I/O thread was registering the
      VIO of a mysql handle (a client API structure that represents a
      connection to another server instance) as a active connection of
      the thread. But under some circumstances such as network failures,
      the client API might destroy the VIO associated with a handle at
      will, yet the VIO wouldn't be properly unregistered. This could
      lead to accesses to freed data if a thread attempted to kill a
      slave I/O thread whose connection was already broken.
      
      There was a attempt to work around this by checking whether
      the socket was being interrupted, but this hack didn't work as
      intended due to the aforementioned race -- attempting to read
      from the socket would yield a "bad file descriptor" error.
      
      The solution is to add a hook to the client API that is called
      from the client code before the VIO of a handle is deleted.
      This hook allows the slave I/O thread to detach the active vio
      so it does not point to freed memory.
      
      server-tools/instance-manager/mysql_connection.cc:
        Add stub method required for linking.
      sql-common/client.c:
        Invoke hook.
      sql/client_settings.h:
        Export hook.
      sql/slave.cc:
        Introduce hook that clears the active VIO before it is freed
        by the client API.
      050c36c7
    • Ramil Kalimullin's avatar
      Fix for bug #46614: Assertion in show_create_trigger() · 3b1280fa
      Ramil Kalimullin authored
      on SHOW CREATE TRIGGER + MERGE table
      
      Problem: SHOW CREATE TRIGGER erroneously relies on fact
      that we have the only underlying table for a trigger
      (wrong for merge tables).
      
      Fix: remove erroneous assert().
      
      
      mysql-test/r/merge.result:
        Fix for bug #46614: Assertion in show_create_trigger() 
        on SHOW CREATE TRIGGER + MERGE table
          - test result.
      mysql-test/t/merge.test:
        Fix for bug #46614: Assertion in show_create_trigger() 
        on SHOW CREATE TRIGGER + MERGE table
          - test case.
      sql/sql_show.cc:
        Fix for bug #46614: Assertion in show_create_trigger() 
        on SHOW CREATE TRIGGER + MERGE table
          - unnecessary assert() removed as we may have more than 1 
        tables open e.g. for a merge table.
      3b1280fa
    • Alfranio Correia's avatar
      BUG#46130 Slave does not correctly handle "expected errors" · 78585a25
      Alfranio Correia authored
      In STATEMENT based replication, a statement that failed on the master but that
      updated non-transactional tables is written to binary log with the error code
      appended to it. On the slave, the statement is executed and the same error is
      expected. However, when an "expected error" did not happen on the slave and was
      either ignored or was related to a concurrency issue on the master, the slave
      did not rollback the effects of the statement and as such inconsistencies might
      happen.
      
      To fix the problem, we automatically rollback a statement that should have
      failed on a slave but succeded and whose expected failure is either ignored or
      stems from a concurrency issue on the master.
      78585a25
    • unknown's avatar
      BUG#45574 CREATE IF NOT EXISTS is not binlogged if the object exists · fce4fa36
      unknown authored
      There is an inconsistency with DROP DATABASE|TABLE|EVENT IF EXISTS and
      CREATE DATABASE|TABLE|EVENT IF NOT EXISTS. DROP IF EXISTS statements are
      binlogged even if either the DB, TABLE or EVENT does not exist. In
      contrast, Only the CREATE EVENT IF NOT EXISTS is binlogged when the EVENT
      exists.  
      
      This patch fixes the following cases for all the replication formats:
      CREATE DATABASE IF NOT EXISTS.
      CREATE TABLE IF NOT EXISTS,
      CREATE TABLE IF NOT EXISTS ... LIKE,
      CREAET TABLE IF NOT EXISTS ... SELECT.
      
      sql/sql_insert.cc:
        Part of the code was moved from the create_table_from_items to select_create::prepare.
        When replication is row based, CREATE TABLE IF NOT EXISTS.. SELECT is binlogged if the table exists.
      fce4fa36
  11. 12 Aug, 2009 3 commits