Let InnoDB use a consistent read when it initializes the auto-inc counter for a table: this will eliminate spurious deadlocks, but will ignore an UPDATE if that happens at the same time that we init the auto-inc counter; this has to be documented; this path also fixes most of Bug #11633, but not all: if ::external_lock() is not called on the table in SHOW TABLE STATUS, that might cause a crash if someone simultaneously DROPs the table
Since UNLOCK TABLES will commit the transaction (and thus release
all InnoDB locks held by it), it is unnecessary to release the
user-requested table locks separately.
Update the InnoDB internal auto-inc counter in ::write_row() if the statement is a REPLACE that fails in a duplicate key error: REPLACE will handle duplicate key error, and the insert will eventually succeed; note that we did NOT change InnoDB's behavior in an UPDATE, because updating the auto-inc counter in an UPDATE would require a bigger patch (Bug #11005)
Ensure that 'null_value' is not accessed before val() is called in FIELD() functions
Fixed initialization of key maps. This fixes some problems with keys when you have more than 64 keys
Fixed that ROLLUP don't always create a temporary table. This fix ensures that func_gconcat.test results are now predictable
Weaken InnoDB table locking at the start of a stored procedure call: this will make multi-transaction stored procedures less deterministic for binlogging, but since they are non-deterministic anyway, it is not that bad; this fix will remove the huge amount of InnoDB tranasctional deadlocks caused by table locking at the start of a stored procedure
The natural InnoDB type for NEWDECIMAL is FIXBINARY, not BINARY, since there probably is no benefit from stripping trailing bytes 0x20; note that tables created with 5.0.6 and containing DECIMAL do not need to be rebuilt, as BINARY works as well; note that because of Jani's fix to bug 10465, tables created with 5.0.? - 5.0.5 DO NEED TO BE REBUILT if they contain DECIMAL
Fix bug #10359 : the critical AUTO-INC bug in InnoDB; since reading of the auto-inc counter in an INSERT was not protected by the AUTO-INC table lock of InnoDB, two inserted rows could get the same value for the auto-inc counter, leading to a duplicate key error
