1. 16 Dec, 2009 2 commits
  2. 15 Dec, 2009 1 commit
    • Mats Kindahl's avatar
      BUG#49618: Field length stored incorrectly in binary log · f43ca025
      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.
      f43ca025
  3. 14 Dec, 2009 2 commits
    • Mats Kindahl's avatar
      WL#5151: Conversion between different types when replicating · c701fe6a
      Mats Kindahl authored
      Fixing minor error when printing SQL types from master and cleaning some code.
      
      Updating result files.
      c701fe6a
    • Mats Kindahl's avatar
      WL#5151: Conversion between different types when replicating · c63df11f
      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.
      c63df11f
  4. 21 Oct, 2009 1 commit
  5. 20 Oct, 2009 1 commit
  6. 19 Oct, 2009 2 commits
  7. 18 Oct, 2009 1 commit
  8. 17 Oct, 2009 1 commit
  9. 16 Oct, 2009 10 commits
  10. 15 Oct, 2009 8 commits
  11. 14 Oct, 2009 11 commits
    • Jorgen Loland's avatar
      merge · aea42df6
      Jorgen Loland authored
      aea42df6
    • Jorgen Loland's avatar
      Followup patch for BUG#47280 · a91b1826
      Jorgen Loland authored
      Temporary tables may set join->group to 0 even though there is 
      grouping. Also need to test if sum_func_count>0 when JOIN::exec() 
      decides whether to present results in a grouped manner.
      a91b1826
    • Georgi Kodinov's avatar
      merge · a820c732
      Georgi Kodinov authored
      a820c732
    • Georgi Kodinov's avatar
      merge · 88aa7af8
      Georgi Kodinov authored
      88aa7af8
    • Georgi Kodinov's avatar
      version change · 8fc8d661
      Georgi Kodinov authored
      8fc8d661
    • Georgi Kodinov's avatar
      merge · 9449be58
      Georgi Kodinov authored
      9449be58
    • Georgi Kodinov's avatar
      merged main to mysql-5.0-bugteam · b251cbd5
      Georgi Kodinov authored
      b251cbd5
    • Georgi Kodinov's avatar
      merged 5.1-main · 4bc86808
      Georgi Kodinov authored
      4bc86808
    • He Zhenxing's avatar
      Attempt to fix Windows testcase output issue · adab17b9
      He Zhenxing authored
      adab17b9
    • Jorgen Loland's avatar
      Bug#47280 - strange results from count(*) with order by multiple · bf0aa2bd
      Jorgen Loland authored
                  columns without where/group
                           
      Simple SELECT with implicit grouping used to return many rows if
      the query was ordered by the aggregated column in the SELECT
      list. This was incorrect because queries with implicit grouping
      should only return a single record.
                                    
      The problem was that when JOIN:exec() decided if execution needed
      to handle grouping, it was assumed that sum_func_count==0 meant
      that there were no aggregate functions in the query. This
      assumption was not correct in JOIN::exec() because the aggregate
      functions might have been optimized away during JOIN::optimize().
                        
      The reason why queries without ordering behaved correctly was
      that sum_func_count is only recalculated if the optimizer chooses
      to use temporary tables (which it does in the ordered case).
      Hence, non-ordered queries were correctly treated as grouped.
                        
      The fix for this bug was to remove the assumption that
      sum_func_count==0 means that there is no need for grouping. This
      was done by introducing variable "bool implicit_grouping" in the
      JOIN object.
      bf0aa2bd
    • sunanda.menon@sun.com's avatar
      85f00a96