Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2.2, 10.3.0, 10.4.0, 10.5.0
Description
MySQL 5.7.29 includes the following fix:
Bug #30287668 INNODB: A LONG SEMAPHORE WAIT
There is no test case. It seems that the problem could occur when a spatial index is large and peculiar enough so that multiple R-tree leaf pages will have the exactly same maximum bounding rectangle (MBR).
The commit message includes the following, suggesting that the hang can occur when index pages are being merged, which should only be possible during transaction rollback or the purge of transaction history:
When we are trying to merge two non-leaf pages of a spatial index the comparison function says that two records in the non-leaf pages are equal. There is no condition written in function rtr_page_copy_rec_list_end_no_locks() to handle this and it loops around this function constantly iterating over the record.
The logic of the fix appears sound, but the implementation is adding yet another parameter to cmp_rec_rec_with_match() that is specific to non-leaf SPATIAL INDEX searches. It should be possible to use a special comparison call in those cases, and avoid bloating the code for normal B-tree indexes. One of rec1,rec2 parameters ought to be guaranteed to point to an index page in the buffer pool, and hence we could probably check page_rec_is_leaf() for the index->is_spatial() case. Also, we might pass the leaf flag from rec_get_offsets() to offset_t in MariaDB.
Attachments
Issue Links
- blocks
-
MDEV-21499 Merge new release of InnoDB 5.7.29 to 10.2
- Closed
- relates to
-
MDEV-21516 Assertion `lock_rec_find_set_bit(lock) == ((ulint)(-1))' failed in lock_rec_free_all_from_discard_page_low on ROLLBACK of SPATIAL INDEX
- Confirmed