When we insert a record into MYISAM table which is almost 'full',
we first write record data in the free space inside a file, and then
check if we have enough space after the end of the file.
So if we don't have the space, table will left corrupted.
Similar error also happens when we updata MYISAM tables.
Fixed by modifying write_dynamic_record and update_dynamic_record functions
to check for free space before writing parts of a record
With certain data sets (when compressed record length gets bigger than
uncompressed) myisamchk --unpack may corrupt data file.
Fixed that record length was wrongly restored from compressed table.
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.
fulltext index
Having a table with broken multibyte characters may cause fulltext
parser dead-loop.
Since normally it is not possible to insert broken multibyte sequence
into a table, this problem may arise only if table is damaged.
Affected statements are:
- CHECK/REPAIR against damaged table with fulltext index;
- boolean mode phrase search against damaged table with or
without fulltext inex;
- boolean mode searches without index;
- nlq searches.
No test case for this fix. Affects 5.0 only.
Fulltext boolean mode phrase search may crash server on platforms
where size of pointer is not equal to size of unsigned integer
(in other words some 64-bit platforms).
The problem was integer overflow.
Affects 4.1 only.
myisam_sort_buffer_size.
An incorrect length of the sort buffer was used when calculating the
maximum number of keys. When myisam_sort_buffer_size is small enough,
this could result in the number of keys < number of
BUFFPEK structures which in turn led to use of uninitialized BUFFPEKs.
Fixed by correcting the buffer length calculation.
As the result of DOUBLE claculations can be bigger
than DBL_MAX constant we use in code, we shouldn't use this constatn
as a biggest possible value.
Particularly the rtree_pick_key function set 'min_area= DBL_MAX' relying
that any rtree_area_increase result will be less so we return valid
key. Though in rtree_area_increase function we calculate the area
of the rectangle, so the result can be 'inf' if the rectangle is
huge enough, which is bigger than DBL_MAX.
Code of the rtree_pick_key modified so we always return a valid key.
When using concurrent insert with parallel index reads, it could
happen that reading sessions found keys that pointed to records
yet to be written to the data file. The result was a report of
a corrupted table. But it was false alert.
When inserting a record in a table with indexes, the keys are
inserted into the indexes before the record is written to the data
file. When the insert happens concurrently to selects, an
index read can find a key that references the record that is not
yet written to the data file. To avoid any access to such record,
the select saves the current end of file position when it starts.
Since concurrent inserts are always appended at end of the data
file, the select can easily ignore any concurrently inserted record.
The problem was that the ignore was only done for non-exact key
searches (partial key or using >, >=, < or <=).
The fix is to ignore concurrently inserted records also for
exact key searches.
No test case. Concurrent inserts cannot be tested with the test
suite. Test cases are attached to the bug report.
INSERT/DELETE/UPDATE followed by ALTER TABLE within LOCK TABLES
may cause table corruption on Windows.
That happens because ALTER TABLE writes outdated shared state
info into index file.
Fixed by removing obsolete workaround.
Affects MyISAM tables on Windows only.
By default MyISAM overwrites .MYD and .MYI files no
DATA DIRECTORY option is used. This can lead to two tables
using the same .MYD and .MYI files (that can't be dropped).
To prevent CREATE TABLE from overwriting a file a new option
is introduced : keep_files_on_create
When this is on the CREATE TABLE throws an error if either
the .MYD or .MYI exists for a MyISAM table.
The option is off by default (resulting in compatible behavior).
Fulltext index may get corrupt by certain gbk characters.
The problem was that when skipping leading non-true-word-characters,
we assumed that these characters are always 1 byte long. This is not
the case with gbk character set, since non-true-word-characters may
be 2 bytes long.
Affects 5.0 only.
Thanks to Martin Friebe for finding and submitting a fix for this bug!
A table with maximum number of key segments and maximum length key name
would have a corrupted .frm file, due to an incorrect calculation of the
complete key length. Now the key length is computed correctly (I hope) :-)
MyISAM would reject a table with the maximum number of keys and the maximum
number of key segments in all keys. It would allow one less than this total
maximum. Now MyISAM accepts a table defined with the maximum. (This is a
very minor issue.)
a lookup into a BINARY index by a key ended with spaces. It caused
an assertion abort for a debug version and wrong results for non-debug
versions.
The problem occurred because the function _mi_pack_key stripped off
the trailing spaces from binary search keys while the function _mi_make_key
did not do it when keys were inserted into the index.
Now the function _mi_pack_key does not remove the trailing spaces from
search keys if they are of the binary type.
- When creating an index for the sort, the number of rows plus 1 is used
to allocate a buffer. In this test case, the number of rows 4294967295
is the max value of an unsigned integer, so when 1 was added to it, a
buffer of size 0 was allocated causing the crash.
- Create new test suite for this bug's test suite as per QA.
