1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-29 05:21:33 +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

@ -35,3 +35,25 @@ id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE a ALL NULL NULL NULL NULL 2 Using where
1 SIMPLE g ref groups_dt groups_dt 70 const,test.a.type 13 Using index condition
drop table t0,t1,t2,t3;
#
# MDEV-35253: xa_prepare_unlock_unmodified fails: shift exponent 32 is too large
#
set @create=
concat("create table t1(",
(select group_concat(concat("col",seq, " int")) from seq_1_to_32),
",\n index idx1(",
(select group_concat(concat("col",seq)) from seq_1_to_32),
")\n)"
);
$create_tbl;
insert into t1() values (),(),();
analyze table t1;
Table Op Msg_type Msg_text
test.t1 analyze status Engine-independent statistics collected
test.t1 analyze status OK
# Must not produce a "shift exponent 32 is too large" runtime ubsan error
explain select * from t1 where col1=1;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 ref idx1 idx1 5 const 1 Using index
drop table t1;
End of 10.5 tests