When calculating the buf pool dirty pages ratio, add also free pages to the LRU list length: no need to active flushing if there are lots of free pages in the buffer pool
Search first only 10 % of the LRU list for a replaceable block before doing an LRU flush; enable again flushing of close pages also in a flush list (checkpointing) flush
trx0trx.c:
Add forgotten return value (it was not used anywhere, fortunately)
ha_innodb.h, mysql_priv.h:
Move declaration of srv_buf_pool_max_modified_pct to ha_innodb.h and enclose it to denote it is a C variable, not C++
Let InnoDB to skip writing of pages from the doublewrite buffer if innodb_force_recovery=6; normally, if the page is corrupt AND the corresponding page in the doublewrite buffer is also corrupt, InnoDB calls exit(1)
Clean up the working of the main thread; add a tunable parameter srv_max_buf_pool_modified_pct which can be used to make the flush phase in shutdown quicker
Clean up the working of the main thread; add a tunable parameter srv_max_buf_pool_modified_pct which can be used to make the flush phase in shutdown quicker
Remove code never actually used in IGNORE; InnoDB just rolls back the latest row insert or update on a duplicate key error and leaves it for MySQL to decide whether to ignore the error
Do not set buffer pool to zero when we start up: that takes too much time for big buffer pools; Purify users must define UNIV_SET_MEM_TO_ZERO in univ.i to eliminate spurious (?) Purify warnings
Make InnoDB to restore old active_index value after a table scan: MySQL may assume that a scan does NOT change active_index; this partially fixes bug 241 of UPDATE ... ORDER BY ... but it still remains that MySQL actually ignores the ORDER BY for both MyISAM and InnoDB tables
log0recv.c:
Use fflush to make sure report of a corrupt log record is printed to .err log before mysqld crashes
Fix bug: we did not allow ON DELETE SET NULL to modify the same table where the delete was made; we can allow it because that cannot produce infinite loops cascaded operations
Fix crash in HANDLER PREV or NEXT if the cursor was positioned using a unique search condition on the primary key: in that case InnoDB does NOT store the cursor position for later fetch prev or next
libraries always ended up in "dir..", even though they were not supposed
to be installed anyway (they are only required at link time). Fixed it by
replacing libs_LIBRARIES with noinst_LIBRARIES for all InnoDB Makefile.am
files and by removing "libsdir = " from innobase/include/Makefile.i .
