[Maria-developers] MDEV-7049 MySQL#74585 - InnoDB: Failing assertion: *mbmaxlen < 5 in file ha_innodb.cc line 1904
Hello Marko, InnoDB uses 5 bits to store the combination of mbminlen and mbmaxlen, and its calculated as: mbmaxlen * 5 + mbminlen Note, combinations with mbminlen=0 and mbmaxlen=0 are not possible. Also, combinations with mbminlen>mbmaxlen are not possible. This is a summary: mbminlen mbmaxlen 0 1 2 3 4 0 (0) (1) (2) (3) (4) 1 (5) 6 (7) (8) (9) 2 (10) 11 12 (13) (14) 3 (15) 16 17 18 (19) 4 (20) 21 22 23 24 I marked impossible numbers with parentheses. In the range 0..24: - 10 pairs are valid - 15 pairs are not valid It should be safe to use any impossible number to mean mbmaxlen=5 & mbminlen=1 It seems there is no really a need to extend the header to use separate 3 bits for both mbminlen and mbmaxlen.
Hi Bar, The purpose of this bit arithmetics (one could say CPU athletics) is to reduce the size of the InnoDB data dictionary cache. If we look at dtype_t and dict_col_t, these are not exactly at any byte boundary at the moment (61 and 84 bits, respectively). I would simply replace the mbminmaxlen field with two 3-bit fields mbminlen, mbmaxlen. This would use up one more bit and would be faster to extract (no multiplication or division, just simple bit-shifting and masking). Also the code would be simpler, because a number of macros would be removed. I think that a similar patch was done in MySQL, but apparently it was never merged to the main trees. Marko On Thu, May 4, 2017 at 1:34 PM, Alexander Barkov <bar@mariadb.org> wrote:
Hello Marko,
InnoDB uses 5 bits to store the combination of mbminlen and mbmaxlen, and its calculated as:
mbmaxlen * 5 + mbminlen
Note, combinations with mbminlen=0 and mbmaxlen=0 are not possible. Also, combinations with mbminlen>mbmaxlen are not possible.
This is a summary:
mbminlen mbmaxlen 0 1 2 3 4 0 (0) (1) (2) (3) (4) 1 (5) 6 (7) (8) (9) 2 (10) 11 12 (13) (14) 3 (15) 16 17 18 (19) 4 (20) 21 22 23 24
I marked impossible numbers with parentheses.
In the range 0..24: - 10 pairs are valid - 15 pairs are not valid
It should be safe to use any impossible number to mean mbmaxlen=5 & mbminlen=1
It seems there is no really a need to extend the header to use separate 3 bits for both mbminlen and mbmaxlen.
-- Marko Mäkelä, Lead Developer InnoDB MariaDB Corporation
Hi Marko, On 05/04/2017 03:01 PM, Marko Mäkelä wrote:
Hi Bar,
The purpose of this bit arithmetics (one could say CPU athletics) is to reduce the size of the InnoDB data dictionary cache. If we look at dtype_t and dict_col_t, these are not exactly at any byte boundary at the moment (61 and 84 bits, respectively).
I would simply replace the mbminmaxlen field with two 3-bit fields mbminlen, mbmaxlen. This would use up one more bit and would be faster to extract (no multiplication or division, just simple bit-shifting and masking). Also the code would be simpler, because a number of macros would be removed. I think that a similar patch was done in MySQL, but apparently it was never merged to the main trees.
Thanks for clarification. So it's about in-memory format. Then the things are even simpler. For some reasons I thought that the problem is with disk format, which is not desirable to change.
Marko
On Thu, May 4, 2017 at 1:34 PM, Alexander Barkov <bar@mariadb.org <mailto:bar@mariadb.org>> wrote:
Hello Marko,
InnoDB uses 5 bits to store the combination of mbminlen and mbmaxlen, and its calculated as:
mbmaxlen * 5 + mbminlen
Note, combinations with mbminlen=0 and mbmaxlen=0 are not possible. Also, combinations with mbminlen>mbmaxlen are not possible.
This is a summary:
mbminlen mbmaxlen 0 1 2 3 4 0 (0) (1) (2) (3) (4) 1 (5) 6 (7) (8) (9) 2 (10) 11 12 (13) (14) 3 (15) 16 17 18 (19) 4 (20) 21 22 23 24
I marked impossible numbers with parentheses.
In the range 0..24: - 10 pairs are valid - 15 pairs are not valid
It should be safe to use any impossible number to mean mbmaxlen=5 & mbminlen=1
It seems there is no really a need to extend the header to use separate 3 bits for both mbminlen and mbmaxlen.
-- Marko Mäkelä, Lead Developer InnoDB MariaDB Corporation
participants (2)
-
Alexander Barkov
-
Marko Mäkelä