MDEV-34784 unhandled FK dependency with DML vs DDL#5041
MDEV-34784 unhandled FK dependency with DML vs DDL#5041
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request addresses MDEV-34784 by ensuring that both parent and child foreign key dependencies are correctly identified and recorded in the write set, preventing issues with parallel applying in Galera clusters. Additionally, it updates InnoDB's lock reporting logic to correctly distinguish between record and table locks during debug output. Review feedback suggests refactoring duplicated logic in wsrep_mysqld.cc and lock0lock.cc to improve maintainability, correcting inconsistent indentation, and removing redundant debug messages.
janlindstrom
left a comment
janlindstrom
left a comment
There was a problem hiding this comment.
Please remove commented code and you could address AI review also. If I correctly remember using lock_rec_print is not safe to call as it expects page to be latched and that might not be always true.
|
|
||
| /* find FK children */ | ||
| { | ||
| //FOREIGN_KEY_INFO *f_key_info; |
There was a problem hiding this comment.
Remove commented code.
| << " that has lock "; | ||
| lock_rec_print(stderr, lock, mtr); | ||
| if (!lock->is_table()) { | ||
| lock_rec_print(stderr, lock, mtr); |
There was a problem hiding this comment.
Is this safe i.e. is page always latched?
Certain DDL statements (e.g. ALTER TABLE) require innodb table lock on tables having foreign key constraint reference to the table under DDL execution. This dependency is not added in write set key information. However, tables being referenced to will be added in the key information, so the table locking domain of DDL is only partially recorded. One harmful consequence of this missing dependency information happens when a DML modifies a FK child table's row, which has NULL in the FK referencing column. In such situation, the FK reference cannot be followed during DDL execution, and there will be no FK parent table keys recorded in the write set. Parallel applying (or multi-master access) of such DML and DDL on the FK parent table will cause applying conflicts. This scenario is presented in a new mtr test added in this commit. The commit has a fix for the DDL FK dependency handling by adding all FK child table names in the write set key information. The commit has also fixes for innodb lock0lock.cc error logging to report lock connflicts of table and record locks correctly.
3 participants
Certain DDL statements (e.g. ALTER TABLE) require innodb table lock on tables having foreign key constraint reference to the table under DDL execution. This dependency is not added in write set key information. However, tables being referenced to will be added in the key information, so the table locking domain of DDL is only partially recorded.
One harmful consequence of this missing dependency information happens when a DML modifies a FK child table's row, which has NULL in the FK referencing column. In such situation, the FK reference cannot be followed during DDL execution, and there will be no FK parent table keys recorded in the write set. Parallel applying (or multi-master access) of such DML and DDL on the FK parent table will cause applying conflicts.
This scenario is presented in a new mtr test added in this commit. The commit has a fix for the DDL FK dependency handling by adding all FK child table names in the write set key information. The commit has also fixes for innodb lock0lock.cc error logging to report lock connflicts of table and record locks correctly.