An error occurred fetching the project authors.
  1. 16 Jan, 2008 1 commit
  2. 18 Dec, 2007 1 commit
    • istruewing@stella.local's avatar
      Bug#32705 - myisam corruption: Key in wrong position · cd1b00e8
      istruewing@stella.local authored
                  at page 1024 with ucs2_bin
      
      Inserting strings with a common prefix into a table with
      characterset UCS2 corrupted the table.
      
      An efficient search method was used, which compares end space
      with ASCII blank. This doesn't work for character sets like UCS2,
      which do not encode blank like ASCII does.
      
      Use the less efficient search method _mi_seq_search()
      for charsets with mbminlen > 1.
      cd1b00e8
  3. 14 Nov, 2007 1 commit
  4. 06 Nov, 2007 1 commit
    • istruewing@stella.local's avatar
      Bug#4692 - DISABLE/ENABLE KEYS waste a space · 30b409bd
      istruewing@stella.local authored
      Disabling and enabling indexes on a non-empty table grows the
      index file.
      
      Disabling indexes just sets a flag per non-unique index and does not
      free the index blocks of the affected indexes. Re-enabling indexes
      creates new indexes with new blocks. The old blocks remain unused
      in the index file.
      
      Fixed by dropping and re-creating all indexes if non-empty disabled
      indexes exist when enabling indexes. Dropping all indexes resets
      the internal end-of-file marker to the end of the index file header.
      It also clears the root block pointers of every index and clears the
      deleted blocks chains. This way all blocks are declared as free.
      30b409bd
  5. 22 May, 2007 1 commit
  6. 16 Mar, 2007 1 commit
    • 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
  7. 15 Feb, 2007 1 commit
  8. 24 Jan, 2007 3 commits
  9. 19 Jan, 2007 1 commit
  10. 17 Jan, 2007 3 commits
  11. 05 Jan, 2007 1 commit
  12. 20 Dec, 2006 1 commit
  13. 15 Dec, 2006 1 commit
  14. 14 Dec, 2006 3 commits
  15. 09 Oct, 2006 3 commits
    • istruewing@chilla.local's avatar
      Bug#8283 - OPTIMIZE TABLE causes data loss · 014c1c88
      istruewing@chilla.local authored
      After merge fix. MyISAM version 10.
      014c1c88
    • istruewing@chilla.local's avatar
      Bug#8283 - OPTIMIZE TABLE causes data loss · 5f08a831
      istruewing@chilla.local authored
      OPTIMIZE TABLE with myisam_repair_threads > 1 performs a non-quick 
      parallel repair. This means that it does not only rebuild all 
      indexes, but also the data file.
      
      Non-quick parallel repair works so that there is one thread per 
      index. The first of the threads rebuilds also the new data file.
      
      The problem was that all threads shared the read io cache on the
      old data file. If there were holes (deleted records) in the table,
      the first thread skipped them, writing only contiguous, non-deleted
      records to the new data file. Then it built the new index so that
      its entries pointed to the correct record positions. But the other
      threads didn't know the new record positions, but put the positions
      from the old data file into the index.
      
      The new design is so that there is a shared io cache which is filled
      by the first thread (the data file writer) with the new contiguous
      records and read by the other threads. Now they know the new record
      positions.
      
      Another problem was that for the parallel repair of compressed
      tables a common bit_buff and rec_buff was used. I changed it so
      that thread specific buffers are used for parallel repair.
      
      A similar problem existed for checksum calculation. I made this
      multi-thread safe too.
      5f08a831
    • gkodinov/kgeorge@macbook.local's avatar
      Bug #22781: SQL_BIG_RESULT fails to influence sort plan · 13633864
      gkodinov/kgeorge@macbook.local authored
       Currently SQL_BIG_RESULT is checked only at compile time.
       However, additional optimizations may take place after
       this check that change the sort method from 'filesort'
       to sorting via index. As a result the actual plan
       executed is not the one specified by the SQL_BIG_RESULT
       hint. Similarly, there is no such test when executing
       EXPLAIN, resulting in incorrect output.
       The patch corrects the problem by testing for
       SQL_BIG_RESULT both during the explain and execution
       phases.
      13633864
  16. 07 Sep, 2006 1 commit
  17. 29 Aug, 2006 1 commit
  18. 25 Aug, 2006 1 commit
  19. 10 Aug, 2006 1 commit
  20. 10 Jul, 2006 1 commit
  21. 06 Jul, 2006 1 commit
    • acurtis@xiphis.org's avatar
      Bug#8706 · 86132d5d
      acurtis@xiphis.org authored
        "temporary table with data directory option fails"
        myisam should not use user-specified table name when creating
        temporary tables and use generated connection specific real name.
        Test included.
      86132d5d
  22. 21 Jun, 2006 1 commit
    • svoj@may.pils.ru's avatar
      BUG#20357 - Got error 124 from storage engine using MIN and MAX · 8b98be28
      svoj@may.pils.ru authored
                  functions in queries
      
      Using MAX()/MIN() on table with disabled indexes (by ALTER TABLE)
      results in error 124 (wrong index) from storage engine.
      
      The problem was that optimizer use disabled index to optimize
      MAX()/MIN(). Normally it must skip disabled index and perform
      table scan.
      
      This patch skips disabled indexes for min/max optimization.
      8b98be28
  23. 19 Jun, 2006 1 commit
    • svoj@may.pils.ru's avatar
      BUG#18036 - update of table joined to self reports table as crashed · 37cdb0fb
      svoj@may.pils.ru authored
      Certain updates of table joined to self results in unexpected
      behavior.
      
      The problem was that record cache was mistakenly enabled for
      self-joined table updates. Normally record cache must be disabled
      for such updates.
      
      Fixed wrong condition in code that determines whether to use
      record cache for self-joined table updates.
      
      Only MyISAM tables were affected.
      37cdb0fb
  24. 10 Mar, 2006 1 commit
    • ingo@mysql.com's avatar
      Bug#14980 - COUNT(*) incorrect on MyISAM table with certain INDEX · d0c6eb88
      ingo@mysql.com authored
      For "count(*) while index_column = value" an index read
      is done. It consists of an index scan and retrieval of
      each key.
      
      For efficiency reasons the index scan stores the key in
      the special buffer 'lastkey2' once only. At the first 
      iteration it notes this fact with the flag 
      HA_STATE_RNEXT_SAME in 'info->update'.
      
      For efficiency reasons, the key retrieval for blobs
      does not allocate a new buffer, but uses 'lastkey2'...
      
      Now I clear the HA_STATE_RNEXT_SAME flag whenever the 
      buffer has been polluted. In this case, the index scan
      copies the key value again (and sets the flag again).
      d0c6eb88
  25. 01 Feb, 2006 1 commit
    • ingo@mysql.com's avatar
      Bug#8841 - CHECKSUM TABLE is broken in MyISAM · c5a7bffc
      ingo@mysql.com authored
      There are (at least) two implementations of the checksum
      computation. One is in MyISAM for the quick checksum. It
      is executed on every row change. The other is in the
      SQL layer for the extended checksum. It retrieves all rows
      of a table via the respective storage engine.
      
      In former MySQL versions varchars were stored with their 
      maximum length, but now with their real length similar to
      blobs.
      
      This change had been forgotten to take care of in the
      extended checksum calculation. Hence too much data was
      checksumed. In MyISAM this change had been taken care of 
      already. Only the real data is included in the checksum.
      
      I changed mysql_checksum_table() so that it uses the
      length information of true varchar fields instead
      of the field length like in former varchar 
      implementations.
      c5a7bffc
  26. 22 Nov, 2005 1 commit
  27. 15 Nov, 2005 1 commit
  28. 07 Nov, 2005 1 commit
  29. 28 Oct, 2005 1 commit
  30. 21 Oct, 2005 1 commit
  31. 29 Sep, 2005 1 commit
  32. 23 Sep, 2005 1 commit