An error occurred fetching the project authors.
  1. 17 Mar, 2010 1 commit
    • Mats Kindahl's avatar
      BUG#49618: Field length stored incorrectly in binary log · 2c5f439d
      Mats Kindahl authored
                 for InnoDB
                  
      The class Field_bit_as_char stores the metadata for the
      field incorrecly because bytes_in_rec and bit_len are set
      to (field_length + 7 ) / 8 and 0 respectively, while
      Field_bit has the correct values field_length / 8 and
      field_length % 8.
                  
      Solved the problem by re-computing the values for the
      metadata based on the field_length instead of using the
      bytes_in_rec and bit_len variables.
                  
      To handle compatibility with old server, a table map
      flag was added to indicate that the bit computation is
      exact. If the flag is clear, the slave computes the
      number of bytes required to store the bit field and
      compares that instead, effectively allowing replication
      *without conversion* from any field length that require
      the same number of bytes to store.
      
      
      mysql-test/suite/rpl/t/rpl_typeconv_innodb.test:
        Adding test to check compatibility for bit field
        replication when using InnoDB
      sql/field.cc:
        Extending compatible_field_size() with flags from
        table map to allow fields to check master info.
      sql/field.h:
        Extending compatible_field_size() with flags from
        table map to allow fields to check master info.
      sql/log.cc:
        Removing table map flags since they are not used
        outside table map class.
      sql/log_event.cc:
        Removing flags parameter from table map constructor
        since it is not used and does not have to be exposed.
      sql/log_event.h:
        Adding flag to denote that bit length for bit field type
        is exact and not potentially rounded to even bytes.
      sql/rpl_utility.cc:
        Adding fields to table_def to store table map flags.
      sql/rpl_utility.h:
        Removing obsolete comment and adding flags to store
        table map flags from master.
      2c5f439d
  2. 16 Mar, 2010 1 commit
    • Martin Hansson's avatar
      Bug#47762: Incorrect result from MIN() when WHERE tests NOT · 7dc69322
      Martin Hansson authored
      NULL column for NULL
      
      The optimization to read MIN() and MAX() values from an
      index did not properly handle comparisons with NULL
      values. Fixed by giving up the particular optimization step
      if there are non-NULL safe comparisons with NULL values, as 
      the result is NULL anyway.
      
      Also, Oracle copyright notice was added to all files.
      7dc69322
  3. 21 Jan, 2010 1 commit
    • Luis Soares's avatar
      BUG#49481: RBR: MyISAM and bit fields may cause slave to stop on delete: · 73f10f06
      Luis Soares authored
      cant find record
      
      Some engines return data for the record. Despite the fact that
      the null bit is set for some fields, their old value may still in
      the row. This can happen when unpacking an AI from the binlog on
      top of a previous record in which a field is set to NULL, which
      previously contained a value. Ultimately, this may cause the
      comparison of records to fail when the slave is doing an index or
      range scan.
      
      We fix this by deploying a call to reset() for each field that is
      set to null while unpacking a row from the binary log.
      Furthermore, we also add mixed mode test case to cover the
      scenario where updating and setting a field to null through a
      Query event and later searching it through a rows event will
      succeed.
      
      Finally, we also change the reset() method, from Field_bit class,
      so that it takes into account bits stored among the null bits and
      not only the ones stored in the record.
      
      mysql-test/suite/rpl/t/rpl_set_null_innodb.test:
        InnoDB test.
      mysql-test/suite/rpl/t/rpl_set_null_myisam.test:
        MyISAM test.
      mysql-test/suite/rpl_ndb/t/rpl_ndb_set_null.test:
        NDB test.
      sql/field.h:
        Changed reset so that it also clears the bits
        among the null_bits for the Field_bit class.
      sql/rpl_record.cc:
        Resetting field after setting it to null when unpacking
        row.
      73f10f06
  4. 25 Nov, 2009 1 commit
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · ffea9806
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 3148.8.5
      > revision-id: davi.arnaut@sun.com-20091102112139-pztthzy6qj8jzomn
      > parent: svoj@sun.com-20091103091902-vwszwwpfi1f4zrpn
      > committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
      > branch nick: 48370-5.1
      > timestamp: Mon 2009-11-02 09:21:39 -0200
      > message:
      >   Bug#48370: Absolutely wrong calculations with GROUP BY and decimal fields when using IF
      >   Bug#45261: Crash, stored procedure + decimal
      >   
      >   Revert fix for Bug#45261 due to unforeseen bugs.
      ffea9806
  5. 20 Nov, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #45261 : Crash, stored procedure + decimal · a21cd97c
      Georgi Kodinov authored
      Bug #48370  Absolutely wrong calculations with GROUP BY and
        decimal fields when using IF
      
      Added the test cases in the above two bugs for regression
      testing.
      Added additional tests that demonstrate a incomplete fix.
      Added a new factory method for Field_new_decimal to 
      create a field from an (decimal returning) Item.
      In the new method made sure that all the precision and 
      length variables are capped in a proper way. 
      This is required because Item's can have larger precision
      than the decimal fields and thus need to be capped when
      creating a field based on an Item type.
      Fixed the wrong typecast to Item_decimal.
      a21cd97c
  6. 02 Nov, 2009 1 commit
  7. 29 Sep, 2009 1 commit
    • Davi Arnaut's avatar
      Bug#45567: Fast ALTER TABLE broken for enum and set · 8d3d35ea
      Davi Arnaut authored
      The problem was that appending values to the end of an existing
      ENUM or SET column was being treated as table data modification,
      preventing a immediately (fast) table alteration that occurs when
      only table metadata is being modified.
      
      The cause was twofold: adding a enumeration or set members to the 
      end of the list of valid member values was not being considered
      a "compatible" table alteration, and for SET columns, the check
      was being done upon the max display length and not the underlying
      (pack) length of the field.
      
      The solution is to augment the function that checks wether two ENUM
      or SET fields are compatible -- by comparing the pack lengths and
      performing a limited comparison of the member values.
      
      mysql-test/r/alter_table.result:
        Add test case result for Bug#45567
      mysql-test/t/alter_table.test:
        Add test case for Bug#45567
      sql/field.cc:
        Check whether two fields can be considered 'equal' for table
        alteration purposes. Fields are equal if they retain the same
        pack length and if new members are added to the end of the list.
      sql/field.h:
        Add comment and remove method.
      8d3d35ea
  8. 24 Aug, 2009 1 commit
    • 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
  9. 24 Jun, 2009 1 commit
    • Tatiana A. Nurnberg's avatar
      Bug#43508: Renaming timestamp or date column triggers table copy · 74deaae9
      Tatiana A. Nurnberg authored
      Altering a table to update a column with types DATE or TIMESTAMP
      would incorrectly be seen as a significant change that necessitates
      a slow copy+rename operation instead of a fast update.
      
      There were two problems:
      
      The character set is magically set for TIMESTAMP to be "binary",
      but that was done too deep in field use code for ALTER TABLE to
      know of it.  Now, put that in the constructor for Field_timestamp.
      
      Also, when we set the character set for the new replacement/
      comparison field, also raise the "binary" field flag that tells us
      we should compare it exactly.  That is necessary to match the old
      stored definition.
      
      Next is the problem that the default length for TIMESTAMP and DATE
      fields is different than the length read from the .frm .  The
      compressed size is written to the file, but the human-readable,
      part-delimited length is used as default length.  IIRC, for
      timestamp it was 19!=14, and for date it was 8!=10.  Length
      mismatch causes a table copy.
      
      Also, clean up a place where a comparison function alters one of its
      parameters and replace it with an assertion of the condition it
      mutates.
      74deaae9
  10. 09 Jun, 2009 2 commits
    • Staale Smedseng's avatar
      Bug #43414 Parenthesis (and other) warnings compiling MySQL · a073ee45
      Staale Smedseng authored
      with gcc 4.3.2
            
      Compiling MySQL with gcc 4.3.2 and later produces a number of 
      warnings, many of which are new with the recent compiler
      versions.
            
      This bug will be resolved in more than one patch to limit the
      size of changesets. This is the first patch, fixing a number 
      of the warnings, predominantly "suggest using parentheses 
      around && in ||", and empty for and while bodies.
      a073ee45
    • Staale Smedseng's avatar
      Bug #43414 Parenthesis (and other) warnings compiling MySQL · a092ed1a
      Staale Smedseng authored
      with gcc 4.3.2
      
      Compiling MySQL with gcc 4.3.2 and later produces a number of 
      warnings, many of which are new with the recent compiler
      versions.
      
      This bug will be resolved in more than one patch to limit the
      size of changesets. This is the first patch, fixing a number 
      of the warnings, predominantly "suggest using parentheses 
      around && in ||", and empty for and while bodies.
      a092ed1a
  11. 16 Dec, 2008 1 commit
    • Davi Arnaut's avatar
      Fix warnings and bug spotted by gcc-4.3. · 3ce026ec
      Davi Arnaut authored
      Related to operator precedence and associativity.
      Make the expressions as explicit as possible.
      
      sql/field.h:
        Silence gcc-4.3 warning: be more explicit.
      sql/item.cc:
        Silence gcc-4.3 warning: be more explicit.
      sql/item_sum.cc:
        Silence gcc-4.3 warning: be more explicit.
      sql/log_event.cc:
        Silence gcc-4.3 warning: be more explicit.
      sql/spatial.h:
        Silence gcc-4.3 warning: be more explicit.
      sql/sql_lex.cc:
        Silence gcc-4.3 warning: be more explicit.
      sql/table.h:
        Silence gcc-4.3 warning: be more explicit.
      storage/federated/ha_federated.cc:
        Fix operator precedence bug.
      storage/heap/ha_heap.cc:
        Silence gcc-4.3 warning: be more explicit.
      3ce026ec
  12. 10 Nov, 2008 1 commit
  13. 24 Oct, 2008 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1 · 256f41ed
      Ramil Kalimullin authored
      Problem: mysqld doesn't detect that enum data must be reinserted performing
      'ALTER TABLE' in some cases.
      
      Fix: reinsert data altering an enum field if enum values are changed.
      
      
      mysql-test/r/alter_table.result:
        Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1
          - test result.
      mysql-test/t/alter_table.test:
        Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1
          - test case.
      sql/field.cc:
        Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1
          - Field_enum::is_equal() introduced, which is called to detect that a field
        is changing by 'ALTER TABLE'.
      sql/field.h:
        Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1
          - Field_enum::is_equal() introduced, which is called to detect that a field
        is changing by 'ALTER TABLE'.
      256f41ed
  14. 23 Oct, 2008 1 commit
  15. 20 Sep, 2008 1 commit
    • Kristofer Pettersson's avatar
      Bug#38469 invalid memory read and/or crash with utf8 text field, stored procedure, uservar · f0352e34
      Kristofer Pettersson authored
                  
      A stored procedure involving substrings could crash the server on certain
      platforms because of invalid memory reads.
                
      During storing the new blob-field value, the cached value's address range
      overlapped that of the new field value. This caused problems when the 
      cached value storage was reallocated to provide access for a new 
      characater set representation. The patch checks the address ranges, and if
      they overlap, the new field value is copied to a new storage before it is
      converted to the new character set.
      
      
      mysql-test/r/sp.result:
        Added result set
      mysql-test/t/sp.test:
        Added test case
      sql/field.cc:
        The source and destination address ranges of a character conversion must not overlap or the 'from' address will be invalidated as the temporary value-
        object is re-allocated to fit the new character set.
      sql/field.h:
        Added comments
      f0352e34
  16. 27 Aug, 2008 1 commit
    • Gleb Shchepa's avatar
      Bug #37799: SELECT with a BIT column in WHERE clause · 54a59681
      Gleb Shchepa authored
                  returns unexpected result
      
      If:
        1. a table has a not nullable BIT column c1 with a length
           shorter than 8 bits and some additional not nullable
           columns c2 etc, and
        2. the WHERE clause is like: (c1 = constant) AND c2 ...,
      the SELECT query returns unexpected result set.
      
      
      The server stores BIT columns in a tricky way to save disk
      space: if column's bit length is not divisible by 8, the
      server places reminder bits among the null bits at the start
      of a record. The rest bytes are stored in the record itself,
      and Field::ptr points to these rest bytes.
      
      However if a bit length of the whole column is less than 8,
      there are no remaining bytes, and there is nothing to store in
      the record at its regular place. In this case Field::ptr points
      to bytes actually occupied by the next column in a record.
      If both columns (BIT and the next column) are NOT NULL,
      the Field::eq function incorrectly deduces that this is the
      same column, so query transformation/equal item elimination
      code (see build_equal_items_for_cond) may mix these columns
      and damage conditions containing references to them.
      
      
      mysql-test/r/type_bit.result:
        Added test case for bug #37799.
      mysql-test/t/type_bit.test:
        Added test case for bug #37799.
      sql/field.h:
        1. The Field::eq function has been modified to take types of
        comparing columns into account to distinguish between BIT and
        not BIT columns referencing the same bytes in a record.
        
        2. Unnecessary type comparison has been removed from the
        Field_bit::eq function (moved to Field::eq).
      54a59681
  17. 11 Aug, 2008 1 commit
    • Marc Alff's avatar
      Bug#38296 (low memory crash with many conditions in a query) · e04dfffb
      Marc Alff authored
      This fix is for 5.0 only : back porting the 6.0 patch manually
      
      The parser code in sql/sql_yacc.yy needs to be more robust to out of
      memory conditions, so that when parsing a query fails due to OOM,
      the thread gracefully returns an error.
      
      Before this fix, a new/alloc returning NULL could:
      - cause a crash, if dereferencing the NULL pointer,
      - produce a corrupted parsed tree, containing NULL nodes,
      - alter the semantic of a query, by silently dropping token values or nodes
      
      With this fix:
      - C++ constructors are *not* executed with a NULL "this" pointer
      when operator new fails.
      This is achieved by declaring "operator new" with a "throw ()" clause,
      so that a failed new gracefully returns NULL on OOM conditions.
      
      - calls to new/alloc are tested for a NULL result,
      
      - The thread diagnostic area is set to an error status when OOM occurs.
      This ensures that a request failing in the server properly returns an
      ER_OUT_OF_RESOURCES error to the client.
      
      - OOM conditions cause the parser to stop immediately (MYSQL_YYABORT).
      This prevents causing further crashes when using a partially built parsed
      tree in further rules in the parser.
      
      No test scripts are provided, since automating OOM failures is not
      instrumented in the server.
      Tested under the debugger, to verify that an error in alloc_root cause the
      thread to returns gracefully all the way to the client application, with
      an ER_OUT_OF_RESOURCES error.
      e04dfffb
  18. 24 Jul, 2008 1 commit
    • Kristofer Pettersson's avatar
      Bug#38002 table_cache consumes too much memory with blobs · 54841382
      Kristofer Pettersson authored
           
      Tables in the table definition cache are keeping a cache buffer for blob
      fields which can consume a lot of memory.
          
      This patch introduces a maximum size threshold for these buffers.
      
      
      sql/sql_base.cc:
        Added function free_field_buffers_larger_than to reclaim memory from blob
        field buffers too large to be cached.
      sql/table.cc:
        Added function free_field_buffers_larger_than
      54841382
  19. 30 Jun, 2008 1 commit
    • Mats Kindahl's avatar
      BUG#37426: RBR breaks for CHAR() UTF-8 fields > 85 chars · 711305e2
      Mats Kindahl authored
            
      In order to handle CHAR() fields, 8 bits were reserved for
      the size of the CHAR field. However, instead of denoting the
      number of characters in the field, field_length was used which
      denotes the number of bytes in the field.
      
      Since UTF-8 fields can have three bytes per character (and
      has been extended to have four bytes per character in 6.0),
      an extra two bits have been encoded in the field metadata
      work for fields of type Field_string (i.e., CHAR fields).
      
      Since the metadata word is filled, the extra bits have been
      encoded in the upper 4 bits of the real type (the most 
      significant byte of the metadata word) by computing the
      bitwise xor of the extra two bits. Since the upper 4 bits
      of the real type always is 1111 for Field_string, this 
      means that for fields of length <256, the encoding is
      identical to the encoding used in pre-5.1.26 servers, but
      for lengths of 256 or more, an unrecognized type is formed,
      causing an old slave (that does not handle lengths of 256
      or more) to stop.
      
      
      mysql-test/extra/rpl_tests/rpl_row_basic.test:
        Adding test cases for replicating UTF-8 fields of lengths
        of 256 or more (bytes).
      mysql-test/suite/binlog/r/binlog_base64_flag.result:
        Result file change.
      mysql-test/suite/binlog/t/binlog_base64_flag.test:
        Adding tests to trigger check that an error is generated when replicating from a
        5.1.25 server for tables with a CHAR(128) but not when replicating a table with a
        CHAR(63). Although the bug indicates that the limit is 83, we elected to use CHAR(63)
        since 6.0 uses 4-byte UTF-8, and anything exceeding 63 would then cause the test to fail
        when the patch is merged to 6.0.
      mysql-test/suite/bugs/combinations:
        Adding combinations file to run all bug reports in all binlog modes (where
        applicable).
      mysql-test/suite/bugs/r/rpl_bug37426.result:
        Result file change.
      mysql-test/suite/bugs/t/rpl_bug37426.test:
        Added test for reported bug.
      mysql-test/suite/rpl/r/rpl_row_basic_2myisam.result:
        Result file change.
      mysql-test/suite/rpl/r/rpl_row_basic_3innodb.result:
        Result file change.
      sql/field.cc:
        Encoding an extra two bits in the most significant nibble (4 bits)
        of the metadata word. Adding assertions to ensure that no attempt
        is made to use lengths longer than supported.
        
        Extending compatible_field_size() function with an extra parameter
        holding a Relay_log_instace for error reporting.
        
        Field_string::compatible_field_size() now reports an error if field
        size for a CHAR is >255.
      sql/field.h:
        Field length is now computed from most significant 4 bits
        of metadata word, or is equal to the row pack length if
        there is no metadata.
        
        Extending compatible_field_size() function with an extra parameter
        holding a Relay_log_instace for error reporting.
      sql/rpl_utility.cc:
        Adding relay log parameter to compatible_field_size().
        
        Minor refactoring to eliminate duplicate code.
      sql/slave.cc:
        Extending rpl_master_has_bug() with a single-argument predicate function and
        a parameter to the predicate function. The predicate function can be used to
        test for extra conditions for the bug before writing an error message.
      sql/slave.h:
        Extending rpl_master_has_bug() with a single-argument predicate function and
        a parameter to the predicate function. The predicate function can be used to
        test for extra conditions for the bug before writing an error message.
        
        Also removing gratuitous default argument.
      sql/sql_insert.cc:
        Changing calls to rpl_master_has_bug() to adapt to changed signature.
      711305e2
  20. 19 Jun, 2008 1 commit
    • Gleb Shchepa's avatar
      Fixed bug #37076: TIMESTAMP/DATETIME/DATE values are not · c8bc6a5d
      Gleb Shchepa authored
                        replicated correctly between machines with
                        mixed endiannes
      
      
      mysql-test/extra/rpl_tests/rpl_row_basic.test:
        Added regression test for bug#37076.
      mysql-test/suite/rpl/r/rpl_row_basic_2myisam.result:
        Added regression test for bug#37076.
      mysql-test/suite/rpl/r/rpl_row_basic_3innodb.result:
        Added regression test for bug#37076.
      mysql-test/suite/rpl_ndb/r/rpl_row_basic_7ndb.result:
        Added regression test for bug#37076.
      sql/field.h:
        Fixed bug #37076: TIMESTAMP/DATETIME/DATE values are not
                          replicated correctly between machines with
                          mixed endiannes
        
        pack and unpack virtual methods have been overloaded for
        Field_timestamp (TIMESTAMP domain), Field_datetime (DATETIME
        domain) and Field_date (DATE domain) classes to replicate data
        between platforms with different endiannes in a correct way
        like in Field_long and Field_longlong classes.
        
        Common code have been moved to private handle_int32 and 
        handle_int64 private methods.
      c8bc6a5d
  21. 06 May, 2008 1 commit
    • unknown's avatar
      Partial rollback of fix for bug #30059: End-space truncation is inconsistent · 5a1b7ddb
      unknown authored
      or incorrect.
      
      For better conformance with standard, truncation procedure of CHAR columns
      has been changed to ignore truncation of trailing whitespace characters
      (note has been removed).
      
      Finally, for columns with non-binary charsets:
      
      1. CHAR(N) columns silently ignore trailing whitespace truncation;
      2. VARCHAR and TEXT columns issue Note about truncation.
      
      BLOBs and other columns with BINARY charset are unaffected.
      
      
      
      
      
      mysql-test/r/bdb.result:
        Rollback of bug #30059 fix.
      mysql-test/r/heap.result:
        Rollback of bug #30059 fix.
      mysql-test/r/innodb.result:
        Rollback of bug #30059 fix.
      mysql-test/r/myisam.result:
        Rollback of bug #30059 fix.
      mysql-test/r/strict.result:
        Rollback of bug #30059 fix.
      mysql-test/r/type_binary.result:
        Rollback of bug #30059 fix.
      mysql-test/r/warnings.result:
        Updated test case for bug #30059.
      sql/field.cc:
        Post-commit fix for bug #30059.
        
        The Field_longstr::report_if_important_data method
        has been changed to notify about trailing spaces only if
        the new count_spaces parameter is TRUE.
        
        The Field_string::store method has been changed to
        ignore trailing whitespace truncation (CHAR column
        type).
      sql/field.h:
        Post-commit fix for bug #30059.
        
        The Field_longstr::report_if_important_data method declaration
        has been changed to accept extra parameter: bool count_spaces.
      5a1b7ddb
  22. 29 Feb, 2008 1 commit
    • unknown's avatar
      Bug#23924 general_log truncates queries with character set introducers. · 1ed34fed
      unknown authored
      Problem: logging of utf8-incompatible binary strings didn't work
      Fix: hex-encoding of incompatible sequences.
      
      
      mysql-test/r/log_tables.result:
        Adding test
      mysql-test/t/log_tables.test:
        Adding test
      sql/field.cc:
        Copying with hex escaping
      sql/field.h:
        New field flag
      sql/log.cc:
        Marking the column "general_log.argument" as hex-escaping field.
      sql/sql_string.cc:
        New function to copy strings with hex-encoding of incompatible characters.
      sql/sql_string.h:
        Prototype for the new function
      1ed34fed
  23. 07 Feb, 2008 1 commit
    • unknown's avatar
      Bug#33379: valgrind error in parts/partition_bit_myisam · b2f0ed63
      unknown authored
      Problem was that Field_bit used Field::hash() function that did not
      know about using null-byte for storing bits.
      Resulting in wrong length, which was caught by valgrind.
      
      Solution: created a Field_bit::hash() that uses Field_bit::val_int()
      and my_charset_bin-collation function hash_sort.
      Also use the store function for platform independs
      
      
      mysql-test/r/partition_datatype.result:
        Bug#33379: valgrind error in parts/partition_bit_myisam
        
        result file
        
        enabled bit datatype test
      mysql-test/t/partition_datatype.test:
        Bug#33379: valgrind error in parts/partition_bit_myisam
        
        test file
        
        enabled bit datatype test
      sql/field.cc:
        Bug#33379: valgrind error in parts/partition_bit_myisam
        
        Problem was that Field_bit used Field::hash() function that did not
        know about using null-byte for storing bits.
        Resulting in wrong length.
        
        Solution: created a Field_bit::hash() that uses Field_bit::val_int()
        and my_charset_bin-collation function hash_sort.
        Also use the store function for platform independens.
      sql/field.h:
        Bug#33379: valgrind error in parts/partition_bit_myisam
        
        Problem was that Field_bit used Field::hash() function that did not
        know about using null-byte for storing bits.
        Resulting in wrong length.
        
        Solution: created a Field_bit::hash().
      b2f0ed63
  24. 06 Feb, 2008 1 commit
    • unknown's avatar
      Fixed bug#30059. · 3891d436
      unknown authored
      Server handles truncation for assignment of too-long values
      into CHAR/VARCHAR/TEXT columns in a different ways when the
      truncated characters are spaces:
      1. CHAR(N) columns silently ignore end-space truncation;
      2. TEXT columns post a truncation warning/error in the
         non-strict/strict mode.
      3. VARCHAR columns always post a truncation note in
         any mode.
      
      Space truncation processing has been synchronised over
      CHAR/VARCHAR/TEXT columns: current behavior of VARCHAR
      columns has been propagated as standard.
      
      Binary-encoded string/BLOB columns are not affected.
      
      
      mysql-test/r/heap.result:
        Updated test case for bug#30059.
      mysql-test/r/innodb.result:
        Updated test case for bug#30059.
      mysql-test/r/myisam.result:
        Updated test case for bug#30059.
      mysql-test/r/strict.result:
        Updated test case for bug#30059.
      mysql-test/r/type_binary.result:
        Updated test case for bug#30059.
      mysql-test/r/warnings.result:
        Added test case for bug#30059.
      mysql-test/t/warnings.test:
        Added test case for bug#30059.
      sql/field.cc:
        Fixed bug#30059.
        The report_data_too_long function was replaced with the
        Field_longstr::report_if_important_data method.
        
        The Field_string::store and the Field_blob::store
        methods was synchronized with the Field_varstring::store
        method.
        Changes:
        1. to CHAR(N): posting of space truncation note has been added
           in both (strict and non-strict) modes;
        2. to BLOBs: a check for space truncation has been added,
           a warning in the non-strict mode and an error message in
           the strict mode have been replaced with a truncation note.
        
        Similar parts of Field_string::store, Field_blob::store and
        Field_varstring::store have been moved to the
        Field_longstr::report_if_important_data method.
      sql/field.h:
        Fixed bug#30059.
        The Field_longstr::report_if_important_data method has been declared.
      3891d436
  25. 08 Jan, 2008 1 commit
  26. 21 Dec, 2007 1 commit
    • unknown's avatar
      Bug #33256: CREATE ... SELECT creates obsolete table · 2ae4b047
      unknown authored
       w/ Field_date instead of Field_newdate
        
      Field_date was still used in temp table creation.
      Fixed by using Field_newdate consistently throughout the server
      except when reading tables defined with older MySQL version.
      No test suite is possible because both Field_date and Field_newdate
      return the same values in all the metadata calls. 
      
      
      mysql-test/r/type_decimal.result:
        Bug #33256: removed redundant warnings
      sql/field.h:
        Bug #33256: Add a constructor similar to Field_date::Field_date()
      sql/item.cc:
        Bug #33256: Use Field_newdate instead of Field_date 
        for all temp tables and CREATE .. SELECT
      sql/item_sum.cc:
        Bug #33256: Use Field_newdate instead of Field_date 
        for all temp tables and CREATE .. SELECT
      sql/item_timefunc.cc:
        Bug #33256: Use Field_newdate instead of Field_date 
        for all temp tables and CREATE .. SELECT
      sql/item_timefunc.h:
        Bug #33256: Use Field_newdate instead of Field_date 
        for all temp tables and CREATE .. SELECT
      2ae4b047
  27. 11 Dec, 2007 2 commits
    • unknown's avatar
      Bug#32848: Data type conversion bug in union subselects in MySQL 5.0.38 · 94f75ffc
      unknown authored
      There were two problems when inferring the correct field types resulting from
      UNION queries.
      - If the type is NULL for all corresponding fields in the UNION, the resulting 
        type would be NULL, while the type is BINARY(0) if there is just a single 
        SELECT NULL.
      - If one SELECT in the UNION uses a subselect, a temporary table is created
        to represent the subselect, and the result type defaults to a STRING type,
        hiding the fact that the type was unknown(just a NULL value).
      Fixed by remembering whenever a field was created from a NULL value and pass
      type NULL to the type coercion if that is the case, and creating a string field
      as result of UNION only if the type would otherwise be NULL.
      
      
      mysql-test/r/union.result:
        Bug#32848: Test result
      mysql-test/t/union.test:
        Bug#32848: Test case
      sql/field.cc:
        Bug#32848: Initialization of new field
      sql/field.h:
        Bug#32848: New member to record when a field was created from a NULL value.
      sql/item.cc:
        Bug#32848: 
        A field created from a NULL value will submit NULL as type to the 
        type coercion procedure.
        If Item_type_holder has not inferred the correct type after processing all
        SELECTs in a UNION, a string field is created.
      sql/sql_select.cc:
        Bug#32848: Recording when a field is created from a NULL value.
      94f75ffc
    • unknown's avatar
      Bug#31990: MINUTE() and SECOND() return bogus results when used on a DATE · 08b256f9
      unknown authored
      HOUR(), MINUTE(), ... returned spurious results when used on a DATE-cast.
      This happened because DATE-cast object did not overload get_time() method
      in superclass Item. The default method was inappropriate here and
      misinterpreted the data.
      
      Patch adds missing method; get_time() on DATE-casts now returns SQL-NULL
      on NULL input, 0 otherwise. This coincides with the way DATE-columns
      behave.
      
      Also fixes similar bug in Date-Field now.
      
      
      mysql-test/r/cast.result:
        Show that HOUR(), MINUTE(), ... return sensible values when used
        on DATE-cast objects, namely NULL for NULL-dates and 0 otherwise.
        Show that this coincides with how DATE-columns behave.
      mysql-test/r/type_date.result:
        Show that HOUR(), MINUTE(), ... return sensible values when used
        on DATE-fields.
      mysql-test/t/cast.test:
        Show that HOUR(), MINUTE(), ... return sensible values when used
        on DATE-cast objects, namely NULL for NULL-dates and 0 otherwise.
        Show that this coincides with how DATE-columns behave.
      mysql-test/t/type_date.test:
        Show that HOUR(), MINUTE(), ... return sensible values when used
        on DATE-fields.
      sql/field.cc:
        Add get_time() method to DATE-field object to overload
        the method in Field superclass that would return spurious
        results. Return zero-result.
      sql/field.h:
        Add get_time() declaration to date-field class
      sql/item_timefunc.cc:
        Add get_time() method to DATE-cast object to overload
        the method in Item superclass that would return spurious
        results. Return zero-result; flag NULL if input was NULL.
      sql/item_timefunc.h:
        Add get_time() declaration to DATE-cast object.
      08b256f9
  28. 13 Nov, 2007 1 commit
    • unknown's avatar
      Bug #31158 Spatial, Union, LONGBLOB vs BLOB bug (crops data) · eb347921
      unknown authored
      max_length parameter for BLOB-returning functions must be big enough
      for any possible content. Otherwise the field created for a table
      will be too small.
      
      
      mysql-test/r/gis.result:
        Bug #31158  Spatial, Union, LONGBLOB vs BLOB bug (crops data)
        
        test result
      mysql-test/t/gis.test:
        Bug #31158  Spatial, Union, LONGBLOB vs BLOB bug (crops data)
        
        test case
      sql/field.cc:
        Bug #31158  Spatial, Union, LONGBLOB vs BLOB bug (crops data)
        
        max_field_size used instead of numeric value
      sql/field.h:
        Bug #31158  Spatial, Union, LONGBLOB vs BLOB bug (crops data)
        
        max_field_size constant defined
      sql/item_geofunc.cc:
        Bug #31158  Spatial, Union, LONGBLOB vs BLOB bug (crops data)
        
        max_length parameter fixed
      eb347921
  29. 11 Oct, 2007 1 commit
    • unknown's avatar
      BUG#29549 (Endians: test failures on Solaris): · 06fb8c2d
      unknown authored
      Refactoring code to add parameter to pack() and unpack() functions with
      purpose of indicating if data should be packed in little-endian or
      native order. Using new functions to always pack data for binary log
      in little-endian order. The purpose of this refactoring is to allow
      proper implementation of endian-agnostic pack() and unpack() functions.
      
      Eliminating several versions of virtual pack() and unpack() functions
      in favor for one single virtual function which is overridden in
      subclasses.
      
      Implementing pack() and unpack() functions for some field types that
      packed data in native format regardless of the value of the
      st_table_share::db_low_byte_first flag.
      
      The field types that were packed in native format regardless are:
      Field_real, Field_decimal, Field_tiny, Field_short, Field_medium,
      Field_long, Field_longlong, and Field_blob.
      
      Before the patch, row-based logging wrote the rows incorrectly on
      big-endian machines where the storage engine defined its own
      low_byte_first() to be FALSE on big-endian machines (the default
      is TRUE), while little-endian machines wrote the fields in correct
      order. The only known storage engine that does this is NDB. In effect,
      this means that row-based replication from or to a big-endian
      machine where the table was using NDB as storage engine failed if the
      other engine was either non-NDB or on a little-endian machine.
      
      With this patch, row-based logging is now always done in little-endian
      order, while ORDER BY uses the native order if the storage engine
      defines low_byte_first() to return FALSE for big-endian machines.
      
      In addition, the max_data_length() function available in Field_blob
      was generalized to the entire Field hierarchy to give the maximum
      number of bytes that Field::pack() will write.
      
      
      mysql-test/extra/rpl_tests/rpl_extraMaster_Col.test:
        Sorting by columns that produces deterministic order.
      mysql-test/suite/rpl/r/rpl_extraColmaster_innodb.result:
        Result change.
      mysql-test/suite/rpl/r/rpl_extraColmaster_myisam.result:
        Result change.
      mysql-test/suite/rpl/r/rpl_row_extraColmaster_ndb.result:
        Result change.
      mysql-test/suite/rpl/t/disabled.def:
        Enabling tests.
      mysql-test/suite/rpl/t/rpl_row_mysqlbinlog.test:
        Adding missing sync_slave_with_master causing slave to keep tables
        after shutdown.
      mysql-test/suite/rpl_ndb/t/disabled.def:
        Enabling tests.
      mysql-test/suite/rpl_ndb/t/rpl_ndb_innodb2ndb-slave.opt:
        Adding --new option
      mysql-test/suite/rpl_ndb/t/rpl_ndb_innodb2ndb.test:
        Adding have_log_bin.
      mysql-test/suite/rpl_ndb/t/rpl_ndb_myisam2ndb-slave.opt:
        Adding --new option
      mysql-test/suite/rpl_ndb/t/rpl_ndb_myisam2ndb.test:
        Adding have_log_bin
      mysql-test/t/partition.test:
        Adding have_archive, since that is used in the test.
      sql/field.cc:
        Eliminating all two-argument pack() and unpack() functions and moving
        functionality into the four-argument version. The four argument version
        is introduced so that it is possible to avoid using the storage engine
        default when writing and reading the packed format (the unpacked format
        still uses the storage engine's default). This is used by row-based
        replication to write the fields in a storage engine- and endian-agnostic
        format.
        
        Packing integral and floating-point numbers in little-endian format
        (if requested).
        
        Using pad_char for the field instead of spaces (0x20) when unpacking.
        
        Adding some Doxygen documentation.
        ---
        Adding max_data_length() to denote the maximum number of bytes that
        pack() will write.
        
        Adding casts to remove warnings for debug printouts.
      sql/field.h:
        Eliminating all virtual pack() and unpack() functions except the four-
        argument version, which now is the function that shall be overridden.
        The two-argument versions are convenience functions, to prevent changes
        to code that uses these.
        
        Adding code to pack integer numbers and floating-point numbers in
        little-endian format, if requested.
        ---
        Adding max_data_length() to denote the maximum number of bytes that
        pack() will write.
      sql/log.cc:
        Removing debug printout causing crash when starting NDB on Solaris.
      sql/log_event.cc:
        Adding missing #ifndef causing compile failure. Adding debug printouts.
      sql/rpl_record.cc:
        Debriding code. Using new pack() and unpack() functions to always pack
        fields little-endian. Adding debug printouts.
        ---
        Using max_data_length() when packing field into row.
        
        Adding casts to debug printouts.
      sql/sql_show.cc:
        Adding code that causes crash on Solaris machines since printf() cannot
        handle NULL values for strings properly.
      mysql-test/suite/rpl_ndb/r/rpl_ndb_innodb2ndb.result:
        New BitKeeper file ``mysql-test/suite/rpl_ndb/r/rpl_ndb_innodb2ndb.result''
      mysql-test/suite/rpl_ndb/r/rpl_ndb_myisam2ndb.result:
        New BitKeeper file ``mysql-test/suite/rpl_ndb/r/rpl_ndb_myisam2ndb.result''
      06fb8c2d
  30. 10 Oct, 2007 1 commit
    • unknown's avatar
      Bug #30825: Problems when putting a non-spatial index on a GIS column · aec287fd
      unknown authored
       Fixed the usage of spatial data (and Point in specific) with 
       non-spatial indexes.
       Several problems :
         - The length of the Point class was not updated to include the 
           spatial reference system identifier. Fixed by increasing with 4 
           bytes.
         - The storage length of the spatial columns was not accounting for
           the length that is prepended to it. Fixed by treating the 
           spatial data columns as blobs (and thus increasing the storage
           length)
         - When creating the key image for comparison in index read wrong
           key image was created (the one needed for and r-tree search,
           not the one for b-tree/other search). Fixed by treating the
           spatial data columns as blobs (and creating the correct kind of
           image based on the index type). 
      
      
      mysql-test/r/bdb_gis.result:
        Bug #30825: bdb tests
      mysql-test/r/gis-rtree.result:
        Bug #30825: key length changed
      mysql-test/r/gis.result:
        Bug #30825: MyISAM tests
      mysql-test/r/innodb_gis.result:
        Bug #30825: InnoDB tests
      mysql-test/t/bdb_gis.test:
        Bug #30825: bdb tests
      mysql-test/t/gis.test:
        Bug #30825: MyISAM tests
      mysql-test/t/innodb_gis.test:
        Bug #30825: InnoDB tests
      sql/field.cc:
        Bug #30825: Removed Field_geom::get_key_image as Field_blog::get_key_image 
          takes type parameter into consideration and is a superset of 
          Field_geom::get_key_image()
      sql/field.h:
        Bug #30825: Removed Field_geom::get_key_image as Field_blog::get_key_image 
          takes type parameter into consideration and is a superset of 
          Field_geom::get_key_image()
      sql/sql_select.h:
        Bug #30825: Geometry data are a blob derivate
      sql/sql_table.cc:
        Bug #30825: Increased key length to accomodate for
          spatial reference system identifier (srid)
      sql/sql_yacc.yy:
        Bug #30825: Increased key length to accomodate for
          spatial reference system identifier (srid)
      sql/table.cc:
        Bug #30825: It stores a length for spatial data
         as well, so increase the storage length (as it's
         done for blobs).
      mysql-test/include/gis_keys.inc:
        Bug #30825: Test file for spatial data and non-spatial indexes
      aec287fd
  31. 16 Aug, 2007 1 commit
    • unknown's avatar
      Fix doxygen warnings. · 81e54a4f
      unknown authored
      sql/field.h:
        Fix doxygen warnings - too complex return value type, it choked on it.
      sql/field_conv.cc:
        Fix doxygen warnings - too complex return value type, it choked on it.
      81e54a4f
  32. 10 Aug, 2007 1 commit
    • unknown's avatar
      BUG#22086 : Extra Slave Col: Char(5) on slave and Char(10) on master cause mysqld crash · 9ad300d5
      unknown authored
      This patch adds functionality to row-based replication to ensure the
      slave's column sizes are >= to that of the master.
      
      It also includes some refactoring for the code from WL#3228.
      
      
      mysql-test/extra/rpl_tests/rpl_extraSlave_Col.test:
        BUG#22086 : Extra Slave Col: Char(5) on slave and Char(10) on master cause mysqld crash 
        
        Removed commented out portion of test referenced in bug report. This
        test supports the original request of the bug report.
      mysql-test/suite/rpl/r/rpl_extraCol_innodb.result:
        BUG#22086 : Extra Slave Col: Char(5) on slave and Char(10) on master cause mysqld crash 
        
        New result file for additional test.
      mysql-test/suite/rpl/r/rpl_extraCol_myisam.result:
        BUG#22086 : Extra Slave Col: Char(5) on slave and Char(10) on master cause mysqld crash 
        
        New result file for additional test.
      mysql-test/suite/rpl_ndb/r/rpl_ndb_extraCol.result:
        BUG#22086 : Extra Slave Col: Char(5) on slave and Char(10) on master cause mysqld crash 
        
        New result file for additional test.
      sql/field.cc:
        BUG#22086 : Extra Slave Col: Char(5) on slave and Char(10) on master cause mysqld crash 
        
        This patch refactors the additions made by this bug patch and those
        made by WL#3228. The effort consolidates the large switches on type()
        into functions within the field classes.
      sql/field.h:
        BUG#22086 : Extra Slave Col: Char(5) on slave and Char(10) on master cause mysqld crash 
        
        This patch refactors the additions made by this bug patch and those
        made by WL#3228. The effort consolidates the large switches on type()
        into functions within the field classes.
      sql/log_event.cc:
        BUG#22086 : Extra Slave Col: Char(5) on slave and Char(10) on master cause mysqld crash 
        
        This patch refactors the calc_field_size() method to use the new
        methods implemented in the field classes. It also corrects comments 
        concerning how replication of field metadata works.
      sql/log_event.h:
        BUG#22086 : Extra Slave Col: Char(5) on slave and Char(10) on master cause mysqld crash 
        
        This patch refactors out the calc_field_size() method into the method
        save_field_metadata().
      sql/rpl_utility.cc:
        BUG#22086 : Extra Slave Col: Char(5) on slave and Char(10) on master cause mysqld crash 
        
        This patch adds a method to check the size of the field on the master 
        using the field metadata from WL#3228. Each column is checked to ensure 
        the slave's column is >= to the master's column in size.
      sql/rpl_utility.h:
        BUG#22086 : Extra Slave Col: Char(5) on slave and Char(10) on master cause mysqld crash 
        
        This patch changes the table_def class so that it records the size of
        the metadata. This is a result of refactoring out the calc_field_size()
        method into the method save_field_metadata(). Prevents access via 
        field_metadata(col) to unitialized memory when there is no metadata
        transmitted from the master.
      mysql-test/suite/rpl/r/rpl_row_colSize.result:
        BUG#22086 : Extra Slave Col: Char(5) on slave and Char(10) on master cause mysqld crash 
        
        New result file for additional test.
      mysql-test/suite/rpl/t/rpl_row_colSize.test:
        BUG#22086 : Extra Slave Col: Char(5) on slave and Char(10) on master cause mysqld crash 
        
        Added a test file to test each variable type that relies on field
        metadata from the master.
      mysql-test/include/test_fieldsize.inc:
        BUG#22086 : Extra Slave Col: Char(5) on slave and Char(10) on master cause mysqld crash 
        
        Sub unit file to test each variable type that relies on field
        metadata from the master.
      9ad300d5
  33. 06 Aug, 2007 2 commits
  34. 05 Aug, 2007 1 commit
    • unknown's avatar
      Fix bug #30219. · 4e6e1220
      unknown authored
      This bug manifested itself for queries with grouping by columns of
      the BIT type. It led to wrong comparisons of bit-field values and
      wrong result sets.
      Bit-field values never cannot be compared as binary values. Yet
      the class Field_bit had an implementation of the cmp method that
      compared bit-fields values as binary values. 
      Also the get_image and set_image methods of the base class Field 
      cannot be used for objects of the Field_bit class. 
      Now these methods are declared as virtual and specific implementations
      of the methods are provided for the class Field_bit.
      
      
      mysql-test/r/type_bit.result:
        Added a test case for bug #30219.
      mysql-test/t/type_bit.test:
        Added a test case for bug #30219.
      sql/field.h:
        Fix bug #30219.
        This bug manifested itself for queries with grouping by columns of
        the BIT type. It led to wrong comparisons of bit-field values and
        wrong result sets.
        Bit-field values never cannot be compared as binary values. Yet
        the class Field_bit had an implementation of the cmp method that
        compared bit-fields values as binary values.
        Also the get_image and set_image methods of the base class Field
        cannot be used for objects of the Field_bit class. 
        Now these methods are declared as virtual and specific implementations
        of these methods are provided for the class Field_bit.
      4e6e1220
  35. 03 Aug, 2007 1 commit
    • unknown's avatar
      WL#3228 (NDB) : RBR using different table defs on slave/master · 6df75c85
      unknown authored
        
      This patch removes a portion of the last patch to Field_blob::copy
      after problems found during testing of tests using distinct operations.
      
      
      sql/field.h:
        WL#3228 (NDB) : RBR using different table defs on slave/master
          
        This patch removes a portion of the last patch to Field_blob::copy
        after problems found during testing of tests using distinct operations.
        
        The code uses the old version of teh get_length() method.
      6df75c85
  36. 02 Aug, 2007 2 commits
    • unknown's avatar
      Simplify logging code a bit (to make code smaller and faster) · 720ea404
      unknown authored
      Moved duplicated code to inline function store_timestamp()
      Save thd->time_zone_used when logging to table as CSV internally cases it to be changed
      Added MYSQL_LOCK_IGNORE_FLUSH to log tables to avoid deadlock in case of flush tables.
      Mark log tables with TIMESTAMP_NO_AUTO_SET to avoid automatic timestamping
      Set TABLE->no_replicate on open
      
      
      
      client/mysqlbinlog.cc:
        Fixed several memory leaks (most in case of error situations)
      mysql-test/r/events_logs_tests.result:
        Made long_query_timeout smaller to ensure next query comes into log
      mysql-test/r/variables.result:
        Make it safe to run test with --log
      mysql-test/t/events_logs_tests.test:
        Made long_query_timeout smaller to ensure next query comes into log
      mysql-test/t/variables.test:
        Make it safe to run test with --log
      sql/field.cc:
        Moved duplicated code to inline function store_timestamp()
      sql/field.h:
        Moved duplicated code to inline function store_timestamp()
      sql/handler.cc:
        Reorder checks in likely order
        Simplify checks if we should do binary logging
        (no_replicate is set once and for all when table is opened)
      sql/log.cc:
        Save thd->time_zone_used as CVS internally cases it to be changed
        Use Field_timestamp->store_timestamp instead of automatic timestamps.
        This gives us correct timestamp even if thd->set_time() is not called (in case
        of connect) and we don't have to store thd->query_start_used anymore.
      sql/sql_base.cc:
        Removed not needed comment
        Moved LINT_INIT() to after declaration
        Renamed temporary variable to avoid compiler warning
        Added MYSQL_LOCK_IGNORE_FLUSH to log tables to avoid deadlock in case of flush tables.
        Mark log tables with TIMESTAMP_NO_AUTO_SET to avoid automatic timestamping
      sql/table.cc:
        Set TABLE->no_replicate on open
      720ea404
    • unknown's avatar
      WL#3228 (NDB) : RBR using different table defs on slave/master · 33943431
      unknown authored
      This patch corrects a problem found during testing on Solaris. The code
      changes how length values are retrieved on big endian machines. The
      patch allows the rpl_extraColmaster tests to run on these machines.
      
      
      mysql-test/suite/rpl/r/rpl_row_create_table.result:
        WL#3228 (NDB) : RBR using different table defs on slave/master
        
        New result file with changes from merge of 5.1 main.
      mysql-test/suite/rpl/t/disabled.def:
        WL#3228 (NDB) : RBR using different table defs on slave/master
        
        Disable the rpl_rwo_extraColmaster_ndb test (WL#3915) because the code
        fails on Big Endian machines. See BUG#29549 for more details.
      sql/field.cc:
        WL#3228 (NDB) : RBR using different table defs on slave/master
        
        This patch corrects a problem found during testing on Solaris. The code
        changes how the store_length method processes requests for values on
        big endian machines.
      sql/field.h:
        WL#3228 (NDB) : RBR using different table defs on slave/master
        
        This patch corrects a problem found during testing on Solaris. The code
        changes how the store_length method processes requests for values on
        big endian machines. It also changes the get_packed_length() method to
        use the endian-ness of the host in getting the length + packlength.
      sql/rpl_record.cc:
        WL#3228 (NDB) : RBR using different table defs on slave/master
        
        This patch turns on the little endian switch (db_low_byte_first) in 
        order to ensure the values are unpack correctly from binlog as they
        are stored in little endian format in binlog.
      sql/rpl_utility.cc:
        WL#3228 (NDB) : RBR using different table defs on slave/master
        
        This patch corrects a problem found during testing on Solaris. The code
        changes how the calculated field size method processes requests for 
        values on big endian machines.
      33943431