Bug #48050 | A proposition for the alternative handling of InnoDB semaphore timeouts | ||
---|---|---|---|
Submitted: | 14 Oct 2009 17:56 | Modified: | 13 May 2010 16:12 |
Reporter: | SINISA MILIVOJEVIC | Email Updates: | |
Status: | Verified | Impact on me: | |
Category: | MySQL Server: InnoDB storage engine | Severity: | S4 (Feature request) |
Version: | any | OS: | Any |
Assigned to: | Assigned Account | CPU Architecture: | Any |
[14 Oct 2009 17:56]
SINISA MILIVOJEVIC
[16 Oct 2009 13:59]
Heikki Tuuri
Sinisa, this is very hard to implement. The latches held by a mini-transaction are not a concept of the higher-level user transaction. InnoDB assumes that every mini-transaction always completes, and InnoDB never rolls back any mini-transaction. There is no mechanism to do that. Crashing InnoDB is the only way to 'roll back' a mini-transaction. Some other database brands are able to release latches held by a deadlocked thread. We could call that 'fault-tolerant software', in the spirit of Gray and Reuter. The thread may even check the consistency of the data structures involved. However, we COULD resolve some specific deadlocks of threads if the deadlock is simple. A possible case is a deadlock involving the adaptive hash latch. But if the user encounters that deadlock often, then it is best to switch of the adaptive hash system altogether. Another possible improvement is InnoDB telling mysqld that now I am going to crash the server, please shut down MyISAM and other engines. Assigning Calvin to this feature request.
[22 Jan 2013 19:48]
Sveta Smirnova
Bug #68047 was marked as duplicate of this one.