Merge from 4.0: Fix a theoretical hang over the adaptive hash latch in InnoDB if one runs INSERT ... SELECT ... (binlog not enabled), or a multi-table UPDATE or DELETE, and only the read tables are InnoDB type, the rest are MyISAM; this also fixes bug #7879 for InnoDB type tables
Fix InnoDB critical bug #7496; we scan the InnoDB data dictionary also at a normal mysqld startup, and create the spaces, so that we know the mapping space id -> .ibd file name; fix an infinite loop if DISCARD TABLESPACE coincides with INSERT or some other table operation; fix a potential crash if DISCARD TABLESPACE coincides with a cascaded FOREIGN KEY operation in the same table; do not allow DISCARD TABLESPACE of a referenced table if FOREIGN_KEY_CHECKS=1
Add a comment that no InnoDB table lock is now acquired in LOCK TABLES if AUTOCOMMIT=1. This helps to avoid deadlocks when porting old MyISAM applications to InnoDB.
If AUTOCOMMIT=1, do not acquire an InnoDB table lock in LOCK TABLES; this makes porting of old MyISAM applications to InnoDB easier, since in that mode InnoDB table locks caused deadlocks very easily
Fix for the 0xA0 character problem in the InnoDB FOREIGN KEY parser: if my_isspace() treats 0xA0 as space, then let InnoDB do the same; this might break some multi-byte charset id's, though for big5, ujis, sjis this seems not to change the current behavior (I checked the tables in /share/charsets); this fix must NOT be merged to 4.1 because in 4.1 everything is in UTF-8
Anthony's http://lists.mysql.com/internals/18505 patch for DROP DATABASE broke caused it to return errno if .ibd files were present (bas_ext() was obsolete in ha_innodb.cc); fix this
Manually ported this bug fix from 4.0:
Fix InnoDB bug #6287: if one uses INSERT IGNORE to insert several rows at a time, and the first inserts are ignored because of a duplicate key collision, then InnoDB in a replication slave assigns AUTO_INCREMENT values 1 bigger than in the master
Fix InnoDB bug #6287: if one uses INSERT IGNORE to insert several rows at a time, and the first inserts are ignored because of a duplicate key collision, then InnoDB in a replication slave assigns AUTO_INCREMENT values 1 bigger than in the master
Rename innodb_table_locks_old_behavior -> innodb_table_locks
Set innodb_table_locks to off by default to get same behaviour as in MySQL 4.0.20
(This means that Innodb ignore table locks by default, which makes it easier to combine MyISAM and InnoDB to simulate a transaction)
Simple optimzations and cleanups
Removed compiler warnings and fixed portability issues
Added client functions 'mysql_embedded()' to allow client to check if we are using embedded server
Fixes for purify
Change error code to HA_ERR_ROW_IS_REFERENCED if we cannot DROP a parent table referenced by a FOREIGN KEY constraint; this error number is less misleading than the previous value HA_ERR_CANNOT_ADD_FOREIGN, but misleading still; we should introduce to 5.0 a proper MySQL error code
Fix bug #5137: if innodb_file_per_table was specified, CREATE TEMPORARY TABLE ... TYPE=InnoDB said that cannot find path specified, and made mysqld to exit(1)
Raise maximum column prefix len to 767 bytes, so that MySQL can create a column prefix index of 255 UTF-8 characters (each takes 3 bytes at the maximum); add comments about why innobase_get_at_most_n_mbchars() works ok
dict0mem.h:
Raise maximum column prefix len to 767 bytes, so that MySQL can create a column prefix index of 255 UTF-8 characters (each takes 3 bytes at the maximum)
row0mysql.c:
If MySQL tries to create a column prefix index longer that 255 UTF-8 characters, give an error, and drop the table from the InnoDB internal data dictionary. MySQL did not drop the table there in its own error handling.
A partial bugfix to a multibyte charset / column prefix index bug: my_charpos() does not handle right some cases, we try to mask the bug for ASCII chars < 128 in the UTF-8 charset
column types TIMESTAMP is NOT NULL by default, so in order to have
TIMESTAMP column holding NULL valaues you have to specify NULL as
one of its attributes (this needed for backward compatibility).
Main changes:
Replaced TABLE::timestamp_default_now/on_update_now members with
TABLE::timestamp_auto_set_type flag which is used everywhere
for determining if we should auto-set value of TIMESTAMP field
during this operation or not. We are also use Field_timestamp::set_time()
instead of handler::update_timestamp() in handlers.
