An error occurred fetching the project authors.
  1. 24 Dec, 2009 1 commit
    • Luis Soares's avatar
      BUG#49836: Replication of geometric fields is broken after WL#5151 · dcf8e115
      Luis Soares authored
      Metadata for geometric fields was not being properly stored by
      the slave in its the table definition. This happened because
      MYSQL_TYPE_GEOMETRY was not included in the 'switch... case' that
      handles field metadata according to the field type. Therefore, it
      would default to 0, leading to always have a mismatch between
      master's field and slave fields'. 
      
      We fix this by deploying the missing 'case MYSQL_TYPE_GEOMETRY:'.
      
      mysql-test/extra/rpl_tests/type_conversions.test:
        Added some tests for blob fields and also the particular
        case for replicating from/into BLOB into/from GEOMETRY.
      sql/field.h:
        As requested by Mats, reverted function added by him in
        changeset:
        http://lists.mysql.com/commits/95313
      dcf8e115
  2. 21 Dec, 2009 1 commit
    • Mats Kindahl's avatar
      WL#5151: Conversion between different types when replicating · 060e3ae7
      Mats Kindahl authored
      Bug#49836 reports that the geometry type does not work
      with WL#5151 applied.
      
      The GEOMETRY type inherits the blob comparison function,
      which read the pack length from the metadata. The GEOMETRY
      type does not fill in the metadata with anything sensible,
      so it is always zero, meaning that the pack length for the
      source type is considered zero, rendering it always "smaller"
      than the target type which has pack length 4 (without pointer).
      
      This patch fixes the problem by defining
      Field_geom::pack_length_from_metadata() to always use the
      same as Field_geom::row_pack_length().
      060e3ae7
  3. 15 Dec, 2009 1 commit
    • Mats Kindahl's avatar
      BUG#49618: Field length stored incorrectly in binary log · 9e980bf7
      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.
      9e980bf7
  4. 14 Dec, 2009 1 commit
    • Mats Kindahl's avatar
      WL#5151: Conversion between different types when replicating · 57184380
      Mats Kindahl authored
      Row-based replication requires the types of columns on the
      master and slave to be approximately the same (some safe
      conversions between strings are allowed), but does not
      allow safe conversions between fields of similar types such
      as TINYINT and INT.
      
      This patch implement type conversions between similar fields
      on the master and slave.
      
      The conversions are controlled using a new variable
      SLAVE_TYPE_CONVERSIONS of type SET('ALL_LOSSY','ALL_NON_LOSSY').
      
      Non-lossy conversions are any conversions that do not run the
      risk of losing any information, while lossy conversions can
      potentially truncate the value. The column definitions are
      checked to decide if the conversion is acceptable.
      
      If neither conversion is enabled, it is required that the
      definitions of the columns are identical on master and slave.
      
      Conversion is done by creating an internal conversion table,
      unpacking the master data into it, and then copy the data to
      the real table on the slave.
      
      .bzrignore:
        New files added
      client/Makefile.am:
        New files added
      client/mysqlbinlog.cc:
        Functions in rpl_utility.cc is now needed by mysqlbinlog.cc.
      libmysqld/Makefile.am:
        New files added
      mysql-test/extra/rpl_tests/check_type.inc:
        Test include file to check a single type conversion.
      mysql-test/extra/rpl_tests/rpl_extraSlave_Col.test:
        Switching to use INT instead of TEXT for column that should not have matching types.
      mysql-test/extra/rpl_tests/rpl_row_basic.test:
        Adding code to enable type conversions for BIT tests since InnoDB
        cannot handle them properly due to incorrect information stored as
        metadata.
      mysql-test/extra/rpl_tests/type_conversions.test:
        Test file to check a set of type conversions
        with current settings of slave_type_conversions.
      mysql-test/suite/rpl/t/rpl_typeconv.test:
        Test file to test conversions from master to slave with
        all possible values for slave_type_conversions.
        
        The test also checks that the slave_type_conversions
        variable works as expected.
      sql/field.cc:
        Changing definition of compatible_field_size to both check if 
        two field with identical base types are compatible and give an
        order between them if they are compatible.
        
        This only implement checking on the slave, so it will not affect
        replication from an old master to a new slave.
      sql/field.h:
        Changing prototypes for functions:
        - compatible_field_size()
        - init_for_tmp_table()
        - row_pack_length()
      sql/log_event.cc:
        Changing compability checks to build a conversion table if the fields
        are compatible, but does not have the same base type.
      sql/log_event_old.cc:
        Changing compability checks to build a conversion table if the fields
        are compatible, but does not have the same base type.
      sql/mysql_priv.h:
        Adding global option variable for SLAVE_TYPE_CONVERSIONS
      sql/mysqld.cc:
        Adding SLAVE_TYPE_CONVERSIONS global server variable.
      sql/rpl_record.cc:
        Changing unpack_row to use the conversion table if present.
      sql/rpl_rli.h:
        Removing function get_tabledef and replacing it with get_table_data().
        This function retrieve data for table opened for replication, not just
        table definition.
      sql/rpl_utility.cc:
        Function table_def::compatible_with is changed to compare table on master
        and slave for compatibility and generate a conversions table if they are
        compatible.
        
        Computing real type of fields from metadata for ENUM and SET types.
        Computing pack_length correctly for ENUM, SET, and BLOB types.
        
        Adding optimization to not check compatibility if no
        slave type conversions are enabled.
      sql/rpl_utility.h:
        Changing prototypes since implementation has changed.
        
        Modifying table_def::type() to return real type instead of stored type.
      sql/set_var.cc:
        Adding SLAVE_TYPE_CONVERSIONS variable.
      sql/set_var.h:
        Adding SLAVE_TYPE_CONVERSIONS variable.
      sql/share/errmsg.txt:
        Adding error messages for slave type conversions.
      sql/sql_class.h:
        Adding SLAVE_TYPE_CONVERSIONS variable.
      sql/sql_select.cc:
        Correcting create_virtual_tmp_table() to compute null bit positions
        correctly in the presence of bit fields.
      57184380
  5. 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
  6. 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
  7. 10 Nov, 2009 1 commit
    • Davi Arnaut's avatar
      Backport of Bug#45767 to mysql-next-mr · 891dffa3
      Davi Arnaut authored
      ------------------------------------------------------------
      revno: 3405
      revision-id: davi.arnaut@sun.com-20090626124624-m4wolyo5193j4cu7
      parent: luis.soares@sun.com-20090626113019-1j4mn1jos480u9f3
      committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
      branch nick: mysql-pe
      timestamp: Fri 2009-06-26 09:46:24 -0300
      message:
        Bug#45767: deprecate/remove Field::pack_key, Field::unpack_key, Field::pack_cmp
        
        Remove unused and dead code.
        
        Parts of the patch contributed by Zardosht Kasheff
      891dffa3
  8. 02 Nov, 2009 2 commits
  9. 14 Oct, 2009 1 commit
    • Konstantin Osipov's avatar
      Backport of: · 595b8f92
      Konstantin Osipov authored
      ----------------------------------------------------------
      revno: 2630.22.8
      committer: Konstantin Osipov <konstantin@mysql.com>
      branch nick: mysql-6.0-runtime
      timestamp: Sun 2008-08-10 18:49:52 +0400
      message:
        Get rid of typedef struct for the most commonly used types:
        TABLE, TABLE_SHARE, LEX. This simplifies use of tags
        and forward declarations.
      595b8f92
  10. 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
  11. 28 Sep, 2009 1 commit
  12. 23 Sep, 2009 1 commit
  13. 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
  14. 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
  15. 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
  16. 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
  17. 10 Nov, 2008 1 commit
  18. 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
  19. 23 Oct, 2008 1 commit
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
  26. 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
  27. 05 Mar, 2008 1 commit
    • unknown's avatar
      Bug #33544: UDF_INIT member decimals initialized wrong with · 1d20b6ff
      unknown authored
        STRING_RESULT argument
      
      There is a "magic" number for precision : NOT_FIXED_DEC. 
      This means that the precision is not a fixed number.
      But this constant was re-defined in several files and 
      was not available to the UDF developers.
      
      Moved the NOT_FIXED_DEC definition to the correct header
      and removed the redundant definitions.
      
      
      client/sql_string.cc:
        Bug #33544: moved NOT_FIXED_DEC to the correct header
      client/sql_string.h:
        Bug #33544: moved NOT_FIXED_DEC to the correct header
      include/mysql_com.h:
        Bug #33544: moved NOT_FIXED_DEC to the correct header
      libmysql/libmysql.c:
        Bug #33544: moved NOT_FIXED_DEC to the correct header
      sql/field.h:
        Bug #33544: moved NOT_FIXED_DEC to the correct header
      sql/sql_string.cc:
        Bug #33544: moved NOT_FIXED_DEC to the correct header
      sql/sql_string.h:
        Bug #33544: moved NOT_FIXED_DEC to the correct header
      storage/ndb/include/kernel/signaldata/DictTabInfo.hpp:
        Bug #33544: moved NOT_FIXED_DEC to the correct header
      1d20b6ff
  28. 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
  29. 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
  30. 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
  31. 08 Jan, 2008 1 commit
  32. 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
  33. 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
  34. 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
  35. 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
  36. 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
  37. 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