[MDEV-29742] Assertion `((val << shift) & mask) == (val << shift)' failed in rec_set_bit_field_2 Created: 2022-10-08 Updated: 2022-10-14 Resolved: 2022-10-10 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB |
| Affects Version/s: | 10.3, 10.4, 10.5, 10.6, 10.7, 10.8, 10.9, 10.10 |
| Fix Version/s: | 10.3.37, 10.4.27, 10.5.18, 10.6.11, 10.7.7, 10.8.6, 10.9.4, 10.10.2, 10.11.1 |
| Type: | Bug | Priority: | Major |
| Reporter: | Elena Stepanova | Assignee: | Marko Mäkelä |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Description |
|
Set to Minor because I can only reproduce it on 10.3 debug. Run with
|
| Comments |
| Comment by Marko Mäkelä [ 2022-10-10 ] | ||||||
|
will cause the test to crash just fine in any version. Alternatively, if you disable In InnoDB index pages, index records are identified not only by the key, but also by "heap numbers" which reflect the order in which the records were inserted into the page. The heap numbers 0 and 1 are reserved for the predetermined "infimum" and "supremum" records, and in total there may be up to 8190 user records in a page, because 13 bits are being reserved for the heap number. In the test, the fields of the PRIMARY KEY records are (id,DB_TRX_ID,DB_ROLL_PTR), total 5+2+6+7=15 bytes. Something like 3,200 such records can fit in a page when using innodb_page_size=64k. The fields of the secondary index are just (id), occupying 5+2 bytes each (5 bytes record header and 2 bytes payload). One could fit over 9,000 such records in a page with innodb_page_size=64k if we did not have the limitation with regard to the heap number. In the INSERT…SELECT code path, the following check in btr_cur_optimistic_insert() will prevent this problem, triggering a page split.
In other words, the fix | ||||||
| Comment by Marko Mäkelä [ 2022-10-14 ] | ||||||
|
If the secondary index payload size is at least 4 bytes (say, if the redundant KEY(id) that is duplicating PRIMARY KEY(id) was defined on INT instead of SMALLINT), then less than 7,300 records could fit in a page. An upper bound estimate that pretends that the page header and footer are empty would be 65536/(5+4). The definition id SMALLINT PRIMARY KEY allows us to insert at most 65536 rows into the entire table. If we had a non-redundant index, say, b TINYINT NOT NULL, INDEX(b), then the secondary index record would be (b,id) with a size of 5+1+2=8 bytes. In this case, 65536/8 would yield 8192. If we subtract the page header and footer, we can easily see that we can fit less than 8192 records in a 64-kilobyte page. If we had id TINYINT PRIMARY KEY, then there would be at most 256 records in the entire table, and the 8192-byte heap number limit cannot possibly be exceeded during ALTER TABLE. I do not think that this bug has any practical impact. |