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.
The problem was an ab-use of last_rkey_length.
Formerly we saved the packed key length (of the search key)
in this element. But in certain cases it got replaced by
the (packed) result key length.
Now we use a new element of MI_INFO to save the packed key
length of the search key.
Use 0x.... as strings if 'new' mode. (bug 152)
Don't report -max on windows when InnoDB is enabled. (bug 332)
Reset current_linfo; This could cause a hang when doing PURGE LOGS.
Fix for row numbers in EXPLAIN (bug 322)
Fix that USE_FRM works for all table types (bug 97)
Fixes for embedded server
Made key_cache more configurable
Fixed that one can change key blocksize in MyISAM
A lot of optimizations to make MyISAM slightly faster
Fixed bug in SELECT db1.table.* FROM db1.table,db2.table
Fixed bug in INSERT DELAYED when doing shutdown and a table was locked
Changed that tmp_table_size =4G-1 means unlimited.
