An error occurred fetching the project authors.
  1. 08 Mar, 2007 1 commit
    • istruewing@chilla.local's avatar
      Bug#25673 - spatial index corruption, error 126 · 2d6ad76a
      istruewing@chilla.local authored
                incorrect key file for table
      
      In certain cases it could happen that deleting a row could
      corrupt an RTREE index.
      
      According to Guttman's algorithm, page underflow is handled
      by storing the page in a list for later re-insertion. The
      keys from the stored pages have to be inserted into the
      remaining pages of the same level of the tree. Hence the
      level number is stored in the re-insertion list together
      with the page.
      
      In the MySQL RTree implementation the level counts from zero
      at the root page, increasing numbers for levels down the tree.
      
      If during re-insertion of the keys the tree height grows, all
      level numbers become invalid. The remaining keys will be
      inserted at the wrong level.
      
      The fix is to increment the level numbers stored in the
      reinsert list after a split of the root block during reinsertion.
      2d6ad76a
  2. 19 Dec, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #23578: Corruption prevents Optimize table from working properly with a · 8e036791
      gkodinov/kgeorge@macbook.gmz authored
      spatial index
       While executing OPTIMIZE TABLE on MyISAM tables the server re-creates the
       index file(s) in order to sort them physically by the key. This cannot be 
       done for R-tree indexes as it makes no sense.
       The server was not checking the type of the index and was accessing an 
       R-tree index as if it was a B-tree.
       Fixed by preventing sorting the index file if it contains an R-tree index.  
       
      8e036791
  3. 01 Oct, 2006 1 commit
  4. 29 Sep, 2006 1 commit
  5. 28 Jun, 2006 1 commit
    • ingo@mysql.com's avatar
      Bug#17877 - Corrupted spatial index · d8499f2d
      ingo@mysql.com authored
      CHECK TABLE could complain about a fully intact spatial index.
      A wrong comparison operator was used for table checking. 
      The result was that it checked for non-matching spatial keys. 
      This succeeded if at least two different keys were present, 
      but failed if only the matching key was present.
      
      I fixed the key comparison.
      d8499f2d
  6. 09 Aug, 2005 1 commit
  7. 28 Jul, 2005 1 commit
  8. 29 Apr, 2005 1 commit
  9. 15 Jan, 2005 1 commit
  10. 10 Dec, 2004 1 commit
  11. 06 Dec, 2004 1 commit
  12. 27 May, 2004 1 commit
  13. 08 Apr, 2004 1 commit
  14. 19 Feb, 2004 1 commit
  15. 10 Dec, 2003 1 commit
  16. 18 Mar, 2003 1 commit
  17. 12 Mar, 2003 1 commit