1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-30 16:24:05 +03:00

MDEV-35253: xa_prepare_unlock_unmodified fails: shift exponent 32 is too large

The code in best_access_path() uses PREV_BITS(uint, N) to
compute a bitmap of all keyparts: {keypart0, ... keypart{N-1}).

The problem is that PREV_BITS($type, N) macro code can't handle the case
when N=<number of bits in $type).
Also, why use PREV_BITS(uint, ...) for key part map computations when
we could have used PREV_BITS(key_part_map) ?

Fixed both:
- Change PREV_BITS(type, N) to handle any N in [0; n_bits(type)].
- Change PREV_BITS() to use key_part_map when computing key_part_map bitmaps.
This commit is contained in:
Sergei Petrunia
2024-10-25 15:33:57 +03:00
parent b8c2bd9f69
commit 284593413f
6 changed files with 63 additions and 5 deletions

View File

@ -7797,7 +7797,7 @@ best_access_path(JOIN *join,
loose_scan_opt.check_ref_access_part1(s, key, start_key, found_part);
/* Check if we found full key */
const key_part_map all_key_parts= PREV_BITS(uint, key_parts);
const key_part_map all_key_parts= PREV_BITS(key_part_map, key_parts);
if (found_part == all_key_parts && !ref_or_null_part)
{ /* use eq key */
max_key_part= (uint) ~0;
@ -7935,7 +7935,8 @@ best_access_path(JOIN *join,
*/
if ((found_part & 1) &&
(!(table->file->index_flags(key, 0, 0) & HA_ONLY_WHOLE_INDEX) ||
found_part == PREV_BITS(uint,keyinfo->user_defined_key_parts)))
found_part == PREV_BITS(key_part_map,
keyinfo->user_defined_key_parts)))
{
max_key_part= max_part_bit(found_part);
/*
@ -23636,7 +23637,7 @@ static int test_if_order_by_key(JOIN *join,
if (have_pk_suffix &&
reverse == 0 && // all were =const so far
key_parts == table->key_info[idx].ext_key_parts &&
table->const_key_parts[pk] == PREV_BITS(uint,
table->const_key_parts[pk] == PREV_BITS(key_part_map,
table->key_info[pk].
user_defined_key_parts))
{