1. 05 Jul, 2006 4 commits
  2. 04 Jul, 2006 1 commit
  3. 29 Jun, 2006 1 commit
  4. 28 Jun, 2006 3 commits
    • ingo@mysql.com's avatar
      Bug#14400 - Query joins wrong rows from table which is subject of "concurrent insert" · 99ad23ec
      ingo@mysql.com authored
      It was possible that fetching a record by an exact key value 
      (including the record pointer) could return a record with a 
      different key value. This happened only if a concurrent insert 
      added a record with the searched key value after the fetching 
      statement locked the table for read.
      
      The search succeded on the key value, but the record was
      rejected as it was past the file length that was remembered
      at start of the fetching statement. With other words it was 
      rejected as being a concurrently inserted record.
      
      The action to recover from this problem was to fetch the 
      record that is pointed at by the next key of the index. 
      This was repeated until a record below the file length was 
      found.
      
      I do now avoid this loop if an exact match was searched. 
      If this match is beyond the file length, it is now treated 
      as "key not found". There cannot be another key with the 
      same record pointer.
      99ad23ec
    • ingo@mysql.com's avatar
      Bug#19835 - Binary copy of corrupted tables crash the server when issuing a query · 9dd5bc38
      ingo@mysql.com authored
      A corrupt table with dynamic record format can crash the 
      server when trying to select from it.
              
      I fixed the crash that resulted from the particular type 
      of corruption that has been reported for this bug.
      
      No test case. To test it, one needs a table with a very special
      corruption. The bug report contains a file with such a table.
      9dd5bc38
    • 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
  5. 27 Jun, 2006 6 commits
  6. 26 Jun, 2006 4 commits
  7. 23 Jun, 2006 1 commit
    • bar@mysql.com's avatar
      Bug#11228: DESC shows arbitrary column as "PRI" · cfb08851
      bar@mysql.com authored
        An UNIQUE KEY consisting of NOT NULL columns
        was displayed as PRIMARY KEY in "DESC t1".
        According to the code, that was intentional
        behaviour for some reasons unknown to me.
        This code was written before bitkeeper time,
        so I cannot check who and why made this.
        After discussing on dev-public, a decision
        was made to remove this code
      cfb08851
  8. 22 Jun, 2006 2 commits
  9. 21 Jun, 2006 10 commits
  10. 20 Jun, 2006 8 commits