Do not add + 1 to the InnoDB index cardinality estimate if the B-tree just contains one page; the fix made in March 2004 caused InnoDB systematically to overestimate the cardinality of empty or small tables by 1
InnoDB with UNIV_MEM_DEBUG did not compile because a global variable was forgotten when we put back mem_print_info() functions 2 days ago; add that variable
Put back mem_print_info() functions that are used to analyze memory leaks; Marko removed them by accident in his Feb 20th, 2004 patch; these functions are very important for debugging, and should always be kept in the source code base
Revert the patch that put log debug code behind UNIV_LOG_DEBUG
log0log.ic, log0recv.c, log0log.c, log0log.h:
Revert 1.1730.18.1 about UNIV_LOG_DEBUG: debug code is often needed in debugging the production version
Revert Marko's untested changeset 1.1844.1.6 to the stable 4.0 version; stable 4.0 must NOT BE modified except in case of bugs
srv0que.c, srv0que.h:
new file
Implement ut_realloc
lexyy.c, pars0lex.l:
Start using ut_malloc, ut_free, ut_realloc in pars0lex.l and lexyy.c; mem_realloc was broken; eliminate possible memcpy(NULL, ..., 0) from string_append()
Ensured that all projects compile
Removed compiler warnings
Better setting of server_version variable.
Fix that make_win_src_distribution creates the privilege tables.
Fix a memory corruption bug: in 32-bit computers, every 4 billionth malloc outside innodb_additional_mem_pool_size was mistreated when freeing the memory; this could corrupt the InnoDB additional mem pool and could have caused crashes anywhere, also inside MySQL, or even database corruption! the bug exists also in 3.23 and 4.1; workaround: configure innodb_additional_mem_pool_size big enough
Allocate the table name buffer from the mem heap of a foreign key object rather than pointing to the name buffer in the table object; even though this apparently caused no bugs in RENAME, DROP, ALTER TABLE, or elsewhere, this convention was very prone to memory allocation bugs
Reserve the MySQL LOCK_thread_count mutex when printing thd->query of
an arbitrary transaction; if we are printing thd->query of a transaction that
we know is currently executing inside InnoDB, then we know that MySQL cannot
meanwhile change thd->query, and no need to reserve the MySQL mutex; note
that this patch still leaves open the possibility of races in MySQL's
thd->query_len
