Commit 4158e75d authored by unknown's avatar unknown

Bug#29838 - myisam corruption using concurrent select ... and update

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.


myisam/mi_rkey.c:
  Bug#29838 - myisam corruption using concurrent select ... and update
  Fixed mi_rkey() to always ignore records beyond saved eof.
parent 79073ea7
......@@ -95,45 +95,66 @@ int mi_rkey(MI_INFO *info, byte *buf, int inx, const byte *key, uint key_len,
myisam_read_vec[search_flag], info->s->state.key_root[inx]))
{
/*
If we searching for a partial key (or using >, >=, < or <=) and
the data is outside of the data file, we need to continue searching
for the first key inside the data file
Found a key, but it might not be usable. We cannot use rows that
are inserted by other threads after we got our table lock
("concurrent inserts"). The record may not even be present yet.
Keys are inserted into the index(es) before the record is
inserted into the data file. When we got our table lock, we
saved the current data_file_length. Concurrent inserts always go
to the end of the file. So we can test if the found key
references a new record.
*/
if (info->lastpos >= info->state->data_file_length &&
(search_flag != HA_READ_KEY_EXACT ||
last_used_keyseg != keyinfo->seg + keyinfo->keysegs))
if (info->lastpos >= info->state->data_file_length)
{
/* The key references a concurrently inserted record. */
if (search_flag == HA_READ_KEY_EXACT &&
last_used_keyseg == keyinfo->seg + keyinfo->keysegs)
{
/* Simply ignore the key if it matches exactly. (Bug #29838) */
my_errno= HA_ERR_KEY_NOT_FOUND;
info->lastpos= HA_OFFSET_ERROR;
}
else
{
/*
If searching for a partial key (or using >, >=, < or <=) and
the data is outside of the data file, we need to continue
searching for the first key inside the data file.
*/
do
{
uint not_used[2];
/*
Skip rows that are inserted by other threads since we got a lock
Note that this can only happen if we are not searching after an
full length exact key, because the keys are sorted
according to position
Skip rows that are inserted by other threads since we got
a lock. Note that this can only happen if we are not
searching after a full length exact key, because the keys
are sorted according to position.
*/
if (_mi_search_next(info, keyinfo, info->lastkey,
info->lastkey_length,
myisam_readnext_vec[search_flag],
info->s->state.key_root[inx]))
break;
break; /* purecov: inspected */
/*
Check that the found key does still match the search.
_mi_search_next() delivers the next key regardless of its
value.
*/
if (search_flag == HA_READ_KEY_EXACT &&
ha_key_cmp(keyinfo->seg, key_buff, info->lastkey, use_key_length,
SEARCH_FIND, not_used))
ha_key_cmp(keyinfo->seg, key_buff, info->lastkey,
use_key_length, SEARCH_FIND, not_used))
{
/* purecov: begin inspected */
my_errno= HA_ERR_KEY_NOT_FOUND;
info->lastpos= HA_OFFSET_ERROR;
break;
/* purecov: end */
}
} while (info->lastpos >= info->state->data_file_length);
}
}
}
}
if (share->concurrent_insert)
rw_unlock(&share->key_root_lock[inx]);
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment