[MDEV-8815] InnoDB should refuse to start if crash recovery fails instead of asserting Created: 2015-09-18  Updated: 2015-09-29  Resolved: 2015-09-29

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB, Storage Engine - XtraDB
Affects Version/s: 10.1
Fix Version/s: 10.1.8

Type: Bug Priority: Major
Reporter: Jan Lindström (Inactive) Assignee: Jan Lindström (Inactive)
Resolution: Fixed Votes: 0
Labels: None

Sprint: 10.1.8-3

 Description   

2015-09-16 15:21:28 7fd806d4e780  InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
InnoDB: If you are installing InnoDB, remember that you must create
InnoDB: directories yourself, InnoDB does not create them.
InnoDB: Error: could not open single-table tablespace file ./test/#sql-5a51_9#P#p0.ibd
2015-09-16 15:21:28 140565804279680 [Note] InnoDB: Restoring possible half-written data pages 
2015-09-16 15:21:28 140565804279680 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Set innodb_force_recovery to ignore this error.
2015-09-16 15:21:28 7fd806d4e780  InnoDB: Assertion failure in thread 140565804279680 in file log0recv.cc line 2776
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
150916 15:21:28 [ERROR] mysqld got signal 6 ;



 Comments   
Comment by Jan Lindström (Inactive) [ 2015-09-29 ]

commit c13f4091f57ebe89281f11affac49d191db77e4f
Author: Jan Lindström <jan.lindstrom@mariadb.com>
Date: Tue Sep 29 15:15:28 2015 +0300

MDEV-8815: InnoDB should refuse to start if crash recovery fails instead of asserting

Added error handling to crash recovery so that we stop instead of
asserting.

Generated at Thu Feb 08 07:30:00 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.