MDEV-13498 DELETE with CASCADE constraints takes long time / MDEV-13246
MDEV-13498 is a performance regression that was introduced in MariaDB 10.2.2 by commit fec844ac which introduced some Galera-specific conditions that were being evaluated even if the write-set replication was not enabled. MDEV-13246 Stale rows despite ON DELETE CASCADE constraint is a correctness regression that was introduced by the same commit. Especially the subcondition !(parent && que_node_get_type(parent) == QUE_NODE_UPDATE) which is equivalent to !parent || que_node_get_type(parent) != QUE_NODE_UPDATE makes little sense. If parent==NULL, the evaluation would proceed to the std::find() expression, which would dereference parent. Because no SIGSEGV was observed related to this, we can conclude that parent!=NULL always holds. But then, the condition would be equivalent to que_node_get_type(parent) != QUE_NODE_UPDATE which would not make sense either, because the std::find() expression is actually assuming the opposite when casting parent to upd_node_t*. It looks like this condition never worked properly, or that it was never properly tested, or both. wsrep_must_process_fk(): Helper function to check if FOREIGN KEY constraints need to be processed. Only evaluate the costly std::find() expression when write-set replication is enabled. Also, rely on operator<<(std::ostream&, const id_name_t&) and operator<<(std::ostream&, const table_name_t&) for pretty-printing index and table names. row_upd_sec_index_entry(): Add !wsrep_thd_is_BF() to the condition. This is applying part of "Galera MW-369 FK fixes" https://github.com/codership/mysql-wsrep/commit/f37b79c6dab101310a45a9e8cb23c0f98716da52 that is described by the following part of the commit comment: additionally: skipping wsrep_row_upd_check_foreign_constraint if thd has BF, essentially is applier or replaying This FK check would be needed only for populating parent row FK keys in write set, so no use for appliers
Showing
Please register or sign in to comment