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)
Add a settable session variable innodb_support_xa; setting it to 0 can save up to 10 % of CPU time and 150 bytes of space in each undo log
trx0trx.h, trx0undo.c, trx0trx.c, trx0roll.c:
Enable XA if innodb_support_xa is not set to 0; make prepare to do log fsync's according to innodb_flush_log_at_trx_commit
Make InnoDB-5.0.3 to process log records of 4.1 undo log header create and reuse just like in 4.1; storing XID to the start of the undo log is a separately logged operation; this conforms to Rule 3 of InnoDB redo logging
Fix InnoDB critical bug #7496; we scan the InnoDB data dictionary also at a normal mysqld startup, and create the spaces, so that we know the mapping space id -> .ibd file name; fix an infinite loop if DISCARD TABLESPACE coincides with INSERT or some other table operation; fix a potential crash if DISCARD TABLESPACE coincides with a cascaded FOREIGN KEY operation in the same table; do not allow DISCARD TABLESPACE of a referenced table if FOREIGN_KEY_CHECKS=1
Print progress of background rollback of transactions with more than 1000 undo log entries
srv0start.c, trx0roll.c, log0recv.c, trx0roll.h:
Cleanup background rollback code in crash recovery; do not flush all modified pages from the buffer pool after a crash recovery: this makes mysqld accesible for users more quickly
transactional table locks to tables mentioned in the query. These locks
are released at the end of the transaction automatically.
This is fix for bugs #5655, #5998 and issue #3762.
Print a warning to the .err log if the InnoDB history list length is > 20 000 even though purge reaches the list head; this is to track corruption reported on the MySQL mailing list Nov 9, 2004
lock0lock.c:
Let SHOW INNODB STATUS print the history list length
Fix bug #5960: if one updated a column so that its size changed, or updated it to an externally stored (TEXT or BLOB) value, then ANOTHER externally stored column would show up as 512 bytes of good data + 20 bytes of garbage in a consistent read that fetched the old version of the row
