Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.6.8, 10.6
Description
This issue was found while analysing MDEV-28800. When lock memory started occupying large amount of buffer pool we fail to terminate the transaction with ER_LOCK_TABLE_FULL. It eventually leads to a server crash with Innodb exiting with Fatal Error.
ib::fatal() << "Over 95 percent of the buffer pool is"
|
" occupied by lock heaps"
|
This is a regression looks to have been introduced in 10.6 by
commit b6a2472489accf0ae9ac3655ffe9b2997ab267ba
|
Author: Daniel Black <daniel@mariadb.org>
|
Date: Tue Feb 22 17:42:59 2022 +1100
|
 |
MDEV-27891: SIGSEGV in InnoDB buffer pool resize
|
bool running_out() const
|
{
|
return !recv_recovery_is_on() &&
|
- UNIV_UNLIKELY(UT_LIST_GET_LEN(free) + UT_LIST_GET_LEN(LRU) <
|
- std::min(curr_size, old_size) / 4);
|
+ UT_LIST_GET_LEN(free) + UT_LIST_GET_LEN(LRU) <
|
+ n_chunks_new / 4 * chunks->size;
|
+ }
|
The integer division (n_chunks_new / 4) becomes zero whenever the total number of chunks are < 4 making the check completely ineffective for such cases. Also the check is inaccurate for larger chunks and needs to be corrected.
I will put forward a patch soon.
Attachments
Issue Links
- is caused by
-
MDEV-27891 Delayed SIGSEGV in buf_pool_t::resize on InnoDB buffer pool resize after or during DROP TABLE
- Closed