[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
BLOB
and TEXT
) was exceeded, InnoDB simply removed
the record from the clustered index. In a similar insert, InnoDB would
leak reserved file space extents, which would only be freed at the next
mysqld startup.
BLOB
values, and your log files were
relatively small, InnoDB could in a big BLOB
operation temporarily
write over the log produced after the latest checkpoint. If InnoDB
would crash at that moment, then the crash recovery would fail,
because InnoDB would not be able to scan the log even up to the
latest checkpoint. Starting from this version, InnoDB tries to ensure
the latest checkpoint is young enough. If that is not possible,
InnoDB prints a warning to the `.err' log of MySQL and advises
you to make the log files bigger.
innodb_fast_shutdown=0
had no effect.
CREATE TABLE
ended in a
comment, that could cause a memory overrun.
Operating system error number .. in
a file operation
to the `.err' log in Windows, the error number
explanation was wrong. Workaround: look at section 13.2 of
http://www.innodb.com/ibman.php about Windows
error numbers.
PRIMARY KEY
like in t(a CHAR(200), PRIMARY KEY (a(10)))
on a fixed-length CHAR
column, InnoDB would crash even in a
simple SELECT
. CCHECK TABLE
would report the table as
corrupt, also in the case where the created key was not PRIMARY
.