Fixed bugs:
#16814: SHOW INNODB STATUS format error in LATEST FOREIGN KEY ERROR section
dict_foreign_key_error_report(): Always print a newline after invoking
dict_print_info_on_foreign_key_in_create_format().
#16827: Better InnoDB error message if ibdata files omitted from my.cnf.
#17126: CHECK TABLE on InnoDB causes a short hang during check of adaptive hash.
CHECK TABLE blocking other queries, by releasing the btr_search_latch
periodically during the adaptive hash table validation.
#17405: Valgrind: conditional jump or move depends on uninitialised valuesw.
buf_block_init(): Reset magic_n, buf_fix_count, and io_fix to avoid testing
uninitialised variables.
#18077: InnoDB uses full explicit table locks in stored FUNCTION.
#18238: When locks exhaust the buffer pool, InnoDB does not roll back the trx.
Check in pessimistic insert and update if the buffer pool is exhausted by locks.
#18252: Disk space leaks in updates of InnoDB BLOB rows.
btr_cur_pessimistic_update(): Invoke rec_get_offset() after rec_set_field_extern_bits().
btr_store_big_rec_extern_fields(): Note that offsets will no longer be valid
after calling this function.
#18283: When InnoDB returns error 'lock table full', MySQL can write to binlog too much.
#18384: InnoDB memory leak on duplicate key errors if row has many columns.
row_ins_duplicate_error_in_clust(): Call mem_heap_free(heap) at func_exit if needed.
#18350: Use consistent read in CREATE ... SELECT .. if innodb_locks_unsafe_for_binlog is used.
Added missing DBUG_xxx_RETURN statements
Fixed some usage of not initialized variables (as found by valgrind)
Ensure that we don't remove locked tables used as name locks from open table cache until unlock_table_names() are called.
This was fixed by having drop_locked_name() returning any table used as a name lock so that we can free it in unlock_table_names()
This will allow Tomas to continue with his work to use namelocks to syncronize things.
Note: valgrind still produces a lot of warnings about using not initialized code and shows memory loss errors when running the ndb tests
A table with an on insert trigger was reported as crashed when the insert
was processed with bulk insert mode on (handler::start_bulk_insert).
The trigger was also selecting from the same table, and that caused
the "crash".
The same problem was present when an insert statement, which was processed
in bulk mode, also used a stored function that was reading the same table.
This fix disables bulk inserts if a statement uses functions or invokes
triggers. Implementing more granular checks will require much more code and
therefore can hardly be done in 5.0