For some simple benchmarks, a majority of time was
spend in find_head() which tries to find the best
place to put the record.
The result of this patch is a 2x or more speedup for
inserts without keys for format PAGE. All changes
are only related to how rows are stored
Should fix some of the problems mentioned in:
MDEV-8132 Temporary tables using Aria with very poor performance
MDEV-9079 Aria very slow for internal temporary tables
MDEV-5841 Mariadb very poor temporary performance
The following changes where done:
- For rows with a small row length that fits into
a page (818 bytes with 8192 pages), stop as soon as we
hit a match.
- Added markers full_head_size and full_tail_size that tells
us where to start searching on the bitmap page
- Ensure that page->used_size is correctly updated when
bitmap grows. This allows us to stop searching at used_size
- Added code to check that the bitmap variables are correct.
- Fixed a wrong test where we set "first_bitmap_with_space".
This shouldn't have caused any notable problems.
my_safe_alloca()/my_safe_afree() work as alloca() or malloc()/free()
depending on the memory size to allocate, that is, depending on
reclength here. They only work correctly if reclength doesn't
change in the middle.
May also fix: MDEV-14970 "MariaDB crashed with signal 11 and Aria table"
I am not able to reproduce a crash, however there was no protection in
print_keydup_error() if the storage engine reported the wrong key number.
This patch adds such a protection and should stop any further crashes
in this case.
Other things:
- Added extra protection in Aria to not set errkey to more than number of
keys. (Don't think this is cause of this crash, but better safe than
sorry)
- Extend test_if_equal_repl_errors() to handle different cases of
ER_DUP_ENTRY. This is just mainly precaution for the future.
This bug happens when locking the same Aria "transactional" table
(page format) more then once with LOCK TABLES and inserting into one
of them with INSERT ... SELECT when the table is empty.
Fixed by ensuring we don't use fast bulk insert if table is opened
twice with LOCK TABLES (as this changes table->s->state)
Code changes:
- Added use_count to MARIA_USED_TABLES to be able to check if
table is opened twice for a statement/lock table
- Don't clear history or reset info->start_state if we
don't have versioning. One reason for the bug was
was that info->start_state was set to point to different
states for the two tables. If there is no versioning
info->start_state should always point to info->s->state.common.
Other things:
- Fixed also some typos that was noticed while scanning the code
- More DBUG_PRINT
end_io_call uses uninitialized values from the new_data_cache
As such we the buffer 0 and check this before calling end_io_cache on it.
Thanks Sergey Vojtovich for the review and for this solution.
Found by Coverity (ref 972481).
Coverity report this as:
CID 971840 (#1 of 1): Operands don't affect result (CONSTANT_EXPRESSION_RESULT)
result_independent_of_operands: 4 | (flags & 1) is always true regardless of the values of its operands. This occurs as the logical first operand of "?:".
The C order of precidence has | of higher precidence than ?:. The
intenting implies an | of the 3 terms.
Adjust to intented meaning.
Do not silence uncertain cases, or fix any bugs.
The only functional change should be that ha_federated::extra()
is not calling DBUG_PRINT to report an unhandled case for
HA_EXTRA_PREPARE_FOR_DROP.
Do not silence uncertain cases, or fix any bugs.
The only functional change should be that ha_federated::extra()
is not calling DBUG_PRINT to report an unhandled case for
HA_EXTRA_PREPARE_FOR_DROP.
Problem was two race condtion in Aria page cache:
- find_block() didn't inform free_block() that it had released requests
- free_block() didn't handle pinned blocks, which could happen if
free_block() was called as part of flush. This is fixed by not freeing
blocks that are pinned. This is safe as when maria_close() is called
when last thread is using a table, there can be no pinned blocks. For
other flush calls it's safe to ignore pinned blocks.
