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
remove FIX_GCC_LINKING_PROBLEM and -DDEFINE_CXA_PURE_VIRTUAL
replace echo in configure.in with AC_MSG_WARN/AC_MSG_ERROR
don't set -DUSE_MYSYS_NEW for gcc 2.95
set $USE_MYSYS_NEW even if CXX is g++
yassl bugfixes
instantiate all yassl templates explicitly
Add UNIV_UNLIKELY hint.
lock0lock.c:
Correct the prototypes of lock_deadlock_recursive() and
lock_deadlock_occurs().
data0data.c:
dtuple_convert_big_rec(): Add UNIV_UNLIKELY hint.
ha_innodb.cc:
ha_innobase::write_row(): Correct the type of 'mode'.
Semi-synchronous replication for InnoDB type tables; before telling the client that a commit has been processed, wait that the replication thread has returned from my_net_send() where it sends the binlog to the slave; note that TCP/IP, even with the TCP_NODELAY option does not guarantee that the slave has RECEIVED the data - this is just heuristic at the moment; this is useful in failover: in almost all cases, every transaction that has returned from the commit has been sent and processed in the slave, which makes failover to the slave simpler if the master crashes; the code does not work yet as is, because MySQL should call innobase_report_binlog_offset_and_commit() in a commit; we will most probably return that call to 5.0.x, to make InnoDB Hot Backup and group commit to work again; XA code broke them temporarily in 5.0.3
