Fix BUG#16814: "SHOW INNODB STATUS format error in LATEST FOREIGN KEY ERROR section"
Add a missing newline to the LAST FOREIGN KEY ERROR section in SHOW INNODB STATUS
output.
Fix BUG#18934: "InnoDB crashes when table uses column names like DB_ROW_ID".
Refuse tables that use reserved column names.
table' lockup".
Changes from the innodb-4.1-ss11 snapshot.
Do not call os_file-create_tmpfile() at runtime. Instead, create
a tempfile at startup and guard access to it with a mutex.
Also, fix bugs:
10511: "Wrong padding of UCS2 CHAR columns in ON UPDATE CASCADE";
13778: "If FOREIGN_KEY_CHECKS=0, one can create inconsistent FOREIGN
KEYs". When FOREIGN_KEY_CHECKS=0 we still need to check that
datatypes between foreign key references are compatible.
Also, added test cases (also for bug 9802).
Fix a bug: InnoDB could in a crash recovery print a big false corruption warning if the first page of an ibdata file was 'recreated' in the buffer pool; this could happen, for example, if a table was dropped, and the page used later
data files. Previously, writes were flushed until the doublewrite
buffer was created. That would be too slow on systems where
os_file_flush() [or fsync(2)] is slow. (Bug #12125)
Fix a problem in crash recovery of .ibd files on Windows if the user used lower_case_table_names=0 or 2; the directory scan in crash recovery forgot to put all paths to lower case, so that the tablespace name would be consistent with the internal data dictionary of InnoDB; remember that InnoDB puts internally all database names and table names to lower case on Windows, regardless of the value of lower_case_table_names
Add fault tolerance in the scan of .ibd files at a crash recovery; formerly a single failure of readdir_get_next caused the rest of the directory to be skipped
At the shutdown, write the latest lsn only to the first pages of the ibdata files of the system tablespace, NOT to the .ibd files; writing to tens of thousands .ibd files can take minutes
Do not test the value of err if the lock operation was skipped because innodb_logs_unsafe_for_binlog was TRUE; though this did not cause any bugs visible to the user, because err is inited to DB_SUCCESS at the start of the function row_search_for_mysql()
between two server instances at server shutdown/startup.
This conflict on advisory locks appears to be the result of a bug
in the operating system; these locks should be released when the
files are closed, but somehow that does not always happen
immediately in Linux. (Bug #9381)
Add diagnostic code to track assertion failure in ut_a(cursor->old_stored == BTR_PCUR_OLD_STORED); the failure happened in OPTIMIZE TABLE, and in 4.0.24 in some other context
If MySQL wrote to its binlog, but for some reason trx->update_undo and trx->insert_undo were NULL in InnoDB, then trx->commit_lsn was garbage, and InnoDB could assert in the log flush of trx_commit_complete_for_mysql() (Bug #9277)
If MySQL wrote to its binlog, but for some reason trx->update_undo and trx->insert_undo were NULL in InnoDB, then trx->commit_lsn was garbage, and InnoDB could assert in the log flush of trx_commit_complete_for_mysql() (Bug #9277)
dict_load_table(): Remove the check for row_format=compact for now,
because the flag bit we used (high-order bit of mix_len)
has not been zero for at least two customers.
