Fix the previous bug fix: dropping a table with FOREIGN KEY checks running on it caused a cascade of failed drops while the foreign key check was waiting for a lock
Fix bug: if we dropped a table where an INSERT was waiting for a lock to check a FOREIGN KEY constraint, then an assertion would fail in lock_reset_all_on_table(), since that operation assumes no waiting locks on the table or its records
row0mysql.c:
Fix bug: InnoDB failed to drop a table in the background drop queue if the table was referenced by a foreign key constraint
Fix bug #3478: InnoDB's FOREIGN KEY tables treated table and database names as case-insensitive; RENAME TABLE t to T would hang in an endless loop if t had a foreign key constraint defined on it
dict0dict.c:
Fix bug #3478: InnoDB's FOREIGN KEY tables treated table and database names as case-insensitive; RENAME TABLE t to T would hang in an endless loop if t had a foreign key constraint defined on it; fix also a hang that would occur if one tried in ALTER TABLE or RENAME TABLE to create a foreign key constraint name that collided with another existing name
Fix bug #5180: having a column prefix index in the primary key, and the same column fully in a secondary key could cause an assertion failure in row_build_row_ref()
Fix bug: if we RENAME a table, InnoDB forgot to load the foreign key constraints that reference the new table name, and forgot to check that they are compatible with the table
Fix bug: in a FOREIGN KEY, ON UPDATE CASCADE was not triggered if the update changed a string to another value identical in alphabetical ordering, e.g., abc -> aBc
Allow always DROPping of a table which is only referenced by FOREIGN KEY constraints from the same table
Many files:
Do not let REPLACE to perform internally an UPDATE if the table is referenced by a FOREIGN KEY: the manual says that REPLACE must resolve a duplicate key error semantically with DELETE(s) + INSERT, and not by an UPDATE; the internal update caused foreign key checks and cascaded operations to behave in a semantically wrong way
Fix bug #2167: generate foreign key id's locally for each table, in the form databasename/tablename_ibfk_number; if the user gives the constraint name explicitly remember it; these changes should ensure that foreign key id's in a slave are the same as in the master, and DROP FOREIGN KEY does not break replication
sync0sync.c:
UNIV_SYNC_DEBUG caused assertion in the creation of the doublewrite buffer, if we do not allow thousands of latches per thread
Remove redundant code; parse both the database name and the table name in a FOREIGN KEY constraint with quotes in mind
row0mysql.c, ha_innodb.cc, sql_table.cc:
Return error message Cannot delete or update a parent row... if we try to drop a table which is referenced by a FOREIGN KEY constraint, and the user has not set foreign_key_checks=0
Fix bug #2483 with InnoDB, UNIQUE secondary index, and NULL values in that unique index; with the IS NULL predicate, InnoDB returned only the first matching row, though there can be many
Fix bug: FOREIGN KEY ... ON UPDATE/DELETE NO ACTION must check the foreign key constraint, not ignore it. Peter Gulutzan said that NO ACTION should check the constraint as deferred, at the end of the SQL statement, while RESTRICT should check it immediately. Since we do not have defered constraints in InnoDB, this bug fix makes InnoDB to check NO ACTION constraints immediately, like it checks RESTRICT constraints.
Fix bug: if one updated a secondary index column so that its alphabetical value did not change (e.g., abc -> aBc) and rolled back the update, InnoDB failed to return the value in the secondary index to its original value
row0upd.h:
Correct typing error
sync0sync.ic:
Remove inadvertently pushed sync debug code
Fix assertion failure on line 713 of row0upd.c if there is a column prefix index and the last characters in the prefix are spaces: do not assume that the length of alphabetically equal strings is the same; fix a buglet which could cause InnoDB to think that a secondary index record was not locked though it had been updated in a way which did not alpahabetically change its value, e.g., abc -> aBc
If innodb_force_recovery >= 5, do not try to fetch an old version of a clustered index record: this reduces crashes when dumping tables from a corrupt database
Fix bug: if one used the rename trick of ibman section 15.1 to recover a temp table, InnoDB asserted because it tried to lock the data dictionary twice
Fix bug: if a primary key contains more than one column, then MySQL seems to do fetch next even for a unique search condition: this in turn caused unnecessary locking which did not agree what the InnoDB manual promised
Remove potential starvation of a full log buffer flush: only flush up to the lsn which was the largest at the time when we requested the full log buffer flush
os0sync.h, os0sync.c:
Fix a bug in os_event on Unix: even though we signaled the event, some threads could continue waiting if the event became nonsignaled quickly again; this made group commit less efficient than it should be
