Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
10.2.8, 10.3.1
Description
If a lock wait occurs during the processing of a FOREIGN KEY constraint, InnoDB will fail to resume the FOREIGN KEY operation once the conflicting lock has been released.
The problem was introduced in MDEV-13331, in the function row_ins_check_foreign_constraint():
err = check_table->to_be_dropped
|
? DB_LOCK_WAIT_TIMEOUT
|
: trx->error_state;
|
We should not assign other values than DB_LOCK_WAIT_TIMEOUT to err here. The following code works both for innodb.foreign_keys and the MySQL 5.7 test innodb.update-cascade which had been missing from MariaDB:
if (check_table->to_be_dropped |
|| trx->error_state == DB_LOCK_WAIT_TIMEOUT) {
|
err = DB_LOCK_WAIT_TIMEOUT;
|
}
|
Attachments
Issue Links
- blocks
-
MDEV-14222 Unnecessary 'cascade' memory allocation for every updated row when there is no FOREIGN KEY
- Closed
-
MDEV-15199 Triangular FKs - Cascade delete causes broken referential integrity
- Closed
- is caused by
-
MDEV-13331 FK DELETE CASCADE does not honor innodb_lock_wait_timeout
- Closed
- relates to
-
MDEV-17541 KILL QUERY during lock wait in FOREIGN KEY check causes hang
- Closed