[MDEV-28601] InnoDB history list length is reverted from 64bit to 32bit int. Created: 2022-05-17 Updated: 2022-05-25 Resolved: 2022-05-25 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB |
| Affects Version/s: | 10.4.0 |
| Fix Version/s: | 10.4.26, 10.5.17, 10.6.9, 10.7.5, 10.8.4, 10.9.2 |
| Type: | Bug | Priority: | Major |
| Reporter: | Matthew Montgomery | Assignee: | Marko Mäkelä |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
In 10.4.x MariaDB changed the size of the rseg_history_len variable during switch to C++ atomics. Compare : This regression remains through to 10.9 https://github.com/MariaDB/server/blob/5dba54bfef31d91c082362065cd091086e20ee9a/storage/innobase/srv/srv0srv.cc#L517 Under 10.3 the value displayed in the information_schema.innodb_metrics name = trx_rseg_history_len truncates at 2^32 size and rolls over to 0. However since the underlying hitory length is still a 64 bit int the size rolls back to >4Bn transcations after some purging has occurred. Under 10.4+ the behavior unknown at rollover. It appears there exists the chance that transactions can remain unpruned after rollover to 0. MySQL 8.0 still uses a 64bit int here. |
| Comments |
| Comment by Marko Mäkelä [ 2022-05-23 ] |
|
The underlying persistent data structure is a linked list. Indeed, it is possible that more than 2³² committed transactions will accumulate, waiting for their history to be purged. Hence, the variables related to the history list length should better be of the type size_t a.k.a. ulint, that is, 32 or 64 bits according to the width of the register file. |
| Comment by Marko Mäkelä [ 2022-05-25 ] |
|
There are 2⁷=128 persistent rollback segments, and each of them may contain up to 2³² uncommitted transactions in the TRX_RSEG_HISTORY list. I think that the maximum number of committed but unpurged transactions is about 2³⁹ and should only be reachable when using innodb_undo_tablespaces=127. The maximum number of transactions is 2⁴⁸; there is no code to handle any wrap-around. |