1. 29 Sep, 2009 4 commits
    • Alfranio Correia's avatar
      BUG#43789 different master/slave table defs cause crash: text/varchar null · 63278c56
      Alfranio Correia authored
                vs not null
      
      NOTE: Backporting the patch to next-mr.
                              
      The replication was generating corrupted data, warning messages on Valgrind
      and aborting on debug mode while replicating a "null" to "not null" field.
      Specifically the unpack_row routine, was considering the slave's table
      definition and trying to retrieve a field value, where there was nothing to be
      retrieved, ignoring the fact that the value was defined as "null" by the master.
                              
      To fix the problem, we proceed as follows:
                              
      1 - If it is not STRICT sql_mode, implicit default values are used, regardless
      if it is multi-row or single-row statement.
                              
      2 - However, if it is STRICT mode, then a we do what follows:
                              
      2.1 If it is a transactional engine, we do a rollback on the first NULL that is
      to be set into a NOT NULL column and return an error.
                              
      2.2 If it is a non-transactional engine and it is the first row to be inserted
      with multi-row, we also return the error. Otherwise, we proceed with the
      execution, use implicit default values and print out warning messages.
                        
      Unfortunately, the current patch cannot mimic the behavior showed by the master
      for updates on multi-tables and multi-row inserts. This happens because such
      statements are unfolded in different row events. For instance, considering the
      following updates and strict mode:
                        
      (master)
      create table t1 (a int);
      create table t2 (a int not null);
      insert into t1 values (1);
      insert into t2 values (2);
      update t1, t2 SET t1.a=10, t2.a=NULL;
                        
      t1 would have (10) and t2 would have (0) as this would be handled as a
      multi-row update. On the other hand, if we had the following updates:
                        
      (master)
      create table t1 (a int);
      create table t2 (a int);
                        
      (slave)
      create table t1 (a int);
      create table t2 (a int not null);
                        
      (master)
      insert into t1 values (1);
      insert into t2 values (2);
      update t1, t2 SET t1.a=10, t2.a=NULL;
                        
      On the master t1 would have (10) and t2 would have (NULL). On
      the slave, t1 would have (10) but the update on t1 would fail.
      63278c56
    • Alfranio Correia's avatar
      BUG#38173 Field doesn't have a default value with row-based replication · bbc830f7
      Alfranio Correia authored
      NOTE: Backporting the patch to next-mr.
            
      The reason of  the bug was incompatibile with the master side behaviour.
      INSERT query on the master is allowed to insert into a table without specifying
      values of DEFAULT-less fields if sql_mode is not strict.
                  
      Fixed with checking sql_mode by the sql thread to decide how to react.
      Non-strict sql_mode should allow Write_rows event to complete.
                  
      todo: warnings can be shown via show slave status, still this is a 
      separate rather general issue how to show warnings for the slave threads.
      bbc830f7
    • Alfranio Correia's avatar
      WL#4828 and BUG#45747 · 5280dc82
      Alfranio Correia authored
      NOTE: Backporting the patch to next-mr.
      
      WL#4828 Augment DBUG_ENTER/DBUG_EXIT to crash MySQL in different functions
      -------
      
      The assessment of the replication code in the presence of faults is extremely
      import to increase reliability. In particular, one needs to know if servers
      will either correctly recovery or print out appropriate error messages thus
      avoiding unexpected problems in a production environment.
      
      In order to accomplish this, the current patch refactories the debug macros
      already provided in the source code and introduces three new macros that
      allows to inject faults, specifically crashes, while entering or exiting a
      function or method. For instance, to crash a server while returning from
      the init_slave function (see module sql/slave.cc), one needs to do what
      follows:
      
      1 - Modify the source replacing DBUG_RETURN by DBUG_CRASH_RETURN;
      
        DBUG_CRASH_RETURN(0);
      
      2 - Use the debug variable to activate dbug instructions:
      
        SET SESSION debug="+d,init_slave_crash_return";
      
      The new macros are briefly described below:
      
      DBUG_CRASH_ENTER (function) is equivalent to DBUG_ENTER which registers the
      beginning of a function but in addition to it allows for crashing the server
      while entering the function if the appropriate dbug instruction is activate.
      In this case, the dbug instruction should be "+d,function_crash_enter".
      
      DBUG_CRASH_RETURN (value) is equivalent to DBUG_RETURN which notifies the
      end of a function but in addition to it allows for crashing the server
      while returning from the function if the appropriate dbug instruction is
      activate. In this case, the dbug instruction should be
      "+d,function_crash_return". Note that "function" should be the same string
      used by either the DBUG_ENTER or DBUG_CRASH_ENTER.
      
      DBUG_CRASH_VOID_RETURN (value) is equivalent to DBUG_VOID_RETURN which
      notifies the end of a function but in addition to it allows for crashing
      the server while returning from the function if the appropriate dbug
      instruction is activate. In this case, the dbug instruction should be
      "+d,function_crash_return". Note that "function" should be the same string
      used by either the DBUG_ENTER or DBUG_CRASH_ENTER.
      
      To inject other faults, for instance, wrong return values, one should rely
      on the macros already available. The current patch also removes a set of
      macros that were either not being used or were redundant as other macros
      could be used to provide the same feature. In the future, we also consider
      dynamic instrumentation of the code.
      
      
      BUG#45747 DBUG_CRASH_* is not setting the strict option
      ---------
            
      When combining DBUG_CRASH_* with "--debug=d:t:i:A,file" the server crashes
      due to a call to the abort function in the DBUG_CRASH_* macro althought the
      appropriate keyword has not been set.
      5280dc82
    • Alfranio Correia's avatar
      BUG#44663 Unused replication options prevent server from starting. · f940fe75
      Alfranio Correia authored
      NOTE: Backporting the patch to next-mr.
                  
      The use of option log_slave_updates without log_bin was preventing the server
      from starting. To fix the problem, we replaced the error message and the exit
      call by a warning message.
      f940fe75
  2. 28 Sep, 2009 3 commits
  3. 25 Sep, 2009 1 commit
    • Mats Kindahl's avatar
      Bug #47645: Segmentation fault when out of memory during handlerton initialization · 14cf09c1
      Mats Kindahl authored
      There is a missing check for memory allocation failure when allocating
      memory for the handlerton structure. If the handlerton init function
      tries to de-reference the pointer, it will cause a segmentation fault
      and crash the server.
      
      This patch fixes the problem by not calling the init function if memory
      allocation failed, and instead prints an informative error message and
      reports the error to the caller.
      14cf09c1
  4. 23 Sep, 2009 3 commits
    • Mats Kindahl's avatar
      WL#5016: Fix header file include guards · 4ad8ef06
      Mats Kindahl authored
                  
      Adding header include file guards to files that are missing such.
      4ad8ef06
    • Mats Kindahl's avatar
      Bug #37221: SET AUTOCOMMIT=1 does not commit binary log · 8f35f7c9
      Mats Kindahl authored
      When setting AUTOCOMMIT=1 after starting a transaction, the binary log
      did not commit the outstanding transaction. The reason was that the binary
      log commit function saw the values of the new settings, deciding that there
      were nothing to commit.
      
      Fixed the problem by moving the implicit commit to before the thread option
      flags were changed, so that the binary log sees the old values of the flags
      instead of the values they will take after the statement.
      8f35f7c9
    • Mats Kindahl's avatar
      BUG#29288: myisam transactions replicated to a transactional · 5661e726
      Mats Kindahl authored
      slave leaves slave unstable
      
      Problem: when replicating from non-transactional to
      transactional engine with autocommit off, no BEGIN/COMMIT
      is written to the binlog. When the slave replicates, it
      will start a transaction that never ends.
      
      Fix: Force autocommit=on on slave by always replicating
      autocommit=1 from the master.
      5661e726
  5. 03 Sep, 2009 6 commits
  6. 02 Sep, 2009 17 commits
  7. 01 Sep, 2009 6 commits