Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
5.5(EOL), 10.0(EOL), 10.1(EOL), 10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5
Description
The function trx_undo_rec_copy() calculates the size of the undo log record by assuming that it has been passed a valid pointer to an undo log record in an undo page. Sometimes this does not hold. The error might be caught by an assertion (only in debug builds) or by a failure to allocate a large amount of memory.
Perhaps the function should also take a const buf_block_t& parameter to identify the buffer pool page, and perform some consistency checks? Its callers should check for an error value (a null pointer would seem to be appropriate) and deal accordingly.
- In purge, we should probably just skip the undo log record and move on.
- On MVCC read, we should return an error that the undo log is corrupted.
- On ROLLBACK, we should probably write a message to the error log and not release any locks. Fixing this would require manual intervention.
This ticket is motivated by some MySQL 5.7.30 code changes in this area:
Bug #29448406 TRX_UNDO_REC_COPY NEEDLESSLY RELIES ON BUFFER POOL PAGE ALIGNMENT
Attachments
Issue Links
- blocks
-
MDEV-28349 Provide "crash safe" options for CHECK TABLE and ALTER TABLE ... CHECK PARTITION ...
- Open
- is blocked by
-
MDEV-13542 Crashing on a corrupted page is unhelpful
- Closed
- relates to
-
MDEV-15608 Crash during transaction rollback when using optimistic parallel replication, few threads, non-durable configuration.
- Closed