- Because my_seek actually is capable of returning an error code we should
exploit that in the best possible way.
- There might be kernel errors or other errors we can't predict and capturing
the return value of all system calls gives us better understanding of
possible errors.
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.
Crash may happen when selecting from a merge table that has underlying
tables with less indexes than in a merge table itself.
If number of keys in merge table is not bigger than requested key number,
return error.
- Fix my_read/my_write to handle return values from read/write correctly
- Add debugging 'deprecated function' warning to my_lread/my_lwrite
- Add debugging 'error, read/write interrupt not handled' warning to my_quick_read/my_quick_write
There is no test case associated with these changes. However, this is a conservative change,
and no repeatable test case is available.
The problem is that on some Mac OS X-es the file writing/reading
call with zero bytes to read/write returns error.
So here i try to eliminate that kinds of calls.
event' from master"
Since there is no repeatable test case, and this is obviously wrong, this is
the most conservative change that might possibly work.
The syscall read() wasn't checked for a negative return value for an
interrupted read. The kernel sys_read() returns -EINTR, and the "library"
layer maps that to return value of -1 and sets errno to EINTR. It's
impossible (on Linux) for read() to set errno EINTR without the return
value being -1 .
So, if we're checking for EINTR behavior, we should not require that the
return value be zero.
Too many cursors (more than 1024) could lead to memory corruption.
This affects both, stored routines and C API cursors, and the
threshold is per-server, not per-connection. Similarly, the
corruption could happen when the server was under heavy load
(executing more than 1024 simultaneous complex queries), and this is
the reason why this bug is fixed in 4.1, which doesn't support
cursors.
The corruption was caused by a bug in the temporary tables code, when
an attempt to create a table could lead to a write beyond allocated
space. Note, that only internal tables were affected (the tables
created internally by the server to resolve the query), not tables
created with CREATE TEMPORARY TABLE. Another pre-condition for the
bug is TRUE value of --temp-pool startup option, which, however, is a
default.
The cause of a bug was that random memory was overwritten in
bitmap_set_next() due to out-of-bound memory access.
The bug caused a reported index corruption in the cases when
key_cache_block_size was not a multiple of myisam_block_size,
e.g. when key_cache_block_size=1536 while myisam_block_size=1024.
A wrong cast led to numeric overflow for data files
greater than 4GB. The parallel repair assumed end of
file after reading the amount of data that the file
was bigger than 4GB. It truncated the data file and
noted the number of records it found so far in the
index file header as the number of rows in the table.
Removing the cast fixed the problem.
I added some cosmetic changes too.
The normal repair worked because it uses a different
function to read from the data file.
when high concurrency": remove HASH::current_record and make it
an external search parameter, so that it can not be the cause of a
race condition under high concurrent load.
The bug was in a race condition in table_hash_search,
when column_priv_hash.current_record was overwritten simultaneously
by multiple threads, causing the search for a suitable grant record
to fail.
No test case as the bug is repeatable only under concurrent load.
several times, it was causing corruption of charset data stored in once_mem_pool.
my_end() deallocated once_mem pool, but did not put a flag that charsets have
to be reloaded. The fix addresses this problem.
Bug#13238 mysqldump and mysqladmin hangs
Avoid recursion into init_available_charsets.
Serg's version didn't work for me: I got
double mutex locking.
Pushing this version instead
(It was approved by Serg anyway)
during replication.
Modified my_dir(). Now this function skips hidden and system
files which sometimes are created by Windows.
NOTE. The fix is similar to the previuos one (05 July 2004)
except for correct setting of the 'attrib' variable value
(within the previous fix this variable was left uninitialized
when my_dir() was called with My_flags & MY_WANT_STAT == 0).
