1. 03 Apr, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #27532: wrong results with ORDER/GROUP BY queries containing · 90aa05d2
      igor@olga.mysql.com authored
      IN/BETWEEN predicates in sorting expressions.
      Wrong results may occur when the select list contains an expression
      with IN/BETWEEN predicate that differs from a sorting expression by
      an additional NOT only.
       
      Added the method Item_func_opt_neg::eq to compare correctly expressions
      containing [NOT] IN/BETWEEN.
      The eq method inherited from the Item_func returns TRUE when comparing
      'a IN (1,2)' with 'a NOT IN (1,2)' that is not, of course, correct.  
      90aa05d2
  2. 31 Mar, 2007 1 commit
  3. 30 Mar, 2007 2 commits
  4. 29 Mar, 2007 1 commit
  5. 28 Mar, 2007 9 commits
  6. 27 Mar, 2007 2 commits
    • kent@mysql.com/kent-amd64.(none)'s avatar
      mysql.spec.sh, Makefile.am: · ef530348
      kent@mysql.com/kent-amd64.(none) authored
        Don't use explicit calls to mysql-test-run in spec
      ef530348
    • istruewing@chilla.local's avatar
      Bug#24985 - UTF8 ENUM primary key on MEMORY using BTREE · 8934e4f3
      istruewing@chilla.local authored
                  causes incorrect duplicate entries
      
      Keys for BTREE indexes on ENUM and SET columns of MEMORY tables
      with character set UTF8 were computed incorrectly. Many
      different column values got the same key value.
      
      Apart of possible performance problems, it made unique indexes
      of this type unusable because it rejected many different
      values as duplicates.
      
      The problem was that multibyte character detection was tried
      on the internal numeric column value. Many values were not
      identified as characters. Their key value became blank filled.
      
      Thanks to Alexander Barkov and Ramil Kalimullin for the patch,
      which sets the character set of ENUM and SET key segments to
      the pseudo binary character set.
      8934e4f3
  7. 26 Mar, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz[kgeorge]'s avatar
      Bug #27164: not reseting the data pointer · e6d81ad3
      gkodinov/kgeorge@magare.gmz[kgeorge] authored
       to 0 causes wrong (large) length to be read
       from the row in _mi_calc_blob_length() when 
       storing NULL values in (e.g) POINT columns.
       This large length is then used to allocate
       a block of memory that (on some OSes) causes
       trouble.
       Fixed by calling the base class's 
       Field_blob::reset() from Field_geom::reset()
       that is called when storing a NULL value into
       the column.
      e6d81ad3
  8. 25 Mar, 2007 2 commits
  9. 24 Mar, 2007 1 commit
  10. 23 Mar, 2007 6 commits
  11. 22 Mar, 2007 6 commits
  12. 20 Mar, 2007 1 commit
  13. 19 Mar, 2007 1 commit
  14. 17 Mar, 2007 1 commit
  15. 16 Mar, 2007 2 commits
    • istruewing@chilla.local's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-4.1-engines · 068b237d
      istruewing@chilla.local authored
      into  chilla.local:/home/mydev/mysql-4.1-bug25289
      068b237d
    • istruewing@chilla.local's avatar
      Bug#26231 - select count(*) on myisam table returns wrong value · c33486ff
      istruewing@chilla.local authored
                  when index is used
      
      When the table contained TEXT columns with empty contents
      ('', zero length, but not NULL) _and_ strings starting with
      control characters like tabulator or newline, the empty values
      were not found in a "records in range" estimate. Hence count(*)
      missed these records.
      
      The reason was a different set of search flags used for key
      insert and key range estimation.
      
      I decided to fix the set of flags used in range estimation.
      Otherwise millions of databases around the world would require
      a repair after an upgrade.
      
      The consequence is that the manual must be fixed, which claims
      that TEXT columns are compared with "end space padding". This
      is true for CHAR/VARCHAR but wrong for TEXT. See also bug 21335.
      c33486ff
  16. 15 Mar, 2007 2 commits
    • dlenev@mockturtle.local's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-4.1 · e25ea78f
      dlenev@mockturtle.local authored
      into  mockturtle.local:/home/dlenev/src/mysql-4.1-merge
      e25ea78f
    • dlenev@mockturtle.local's avatar
      Fix for bug #25966 "2MB per second endless memory consumption after LOCK · f2cb6641
      dlenev@mockturtle.local authored
      TABLE ... WRITE".
      
      CPU hogging occured when connection which had to wait for table lock was
      serviced by thread which previously serviced connection that was killed
      (note that connections can reuse threads if thread cache is enabled).
      One possible scenario which exposed this problem was when thread which
      provided binlog dump to replication slave was implicitly/automatically
      killed when the same slave reconnected and started pulling data through
      different thread/connection.
      In 5.* versions memory hogging was added to CPU hogging. Moreover in
      those versions the problem also occured when one killed particular query
      in connection (using KILL QUERY) and later this connection had to wait for
      some table lock.
      
      This problem was caused by the fact that thread-specific mysys_var::abort
      variable, which indicates that waiting operations on mysys layer should
      be aborted (this includes waiting for table locks), was set by kill
      operation but was never reset back. So this value was "inherited" by the
      following statements or even other connections (which reused the same
      physical thread). Such discrepancy between this variable and THD::killed
      flag broke logic on SQL-layer and caused CPU and memory hogging.
      
      This patch tries to fix this problem by properly resetting this member.
      
      There is no test-case associated with this patch since it is hard to test
      for memory/CPU hogging conditions in our test-suite.
      f2cb6641
  17. 14 Mar, 2007 1 commit