Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2.2, 10.3.0
Description
MySQL 5.7.2 introduced heap memory allocations for every updated row:
if (node->cascade_heap) { |
mem_heap_empty(node->cascade_heap);
|
} else { |
node->cascade_heap = mem_heap_create(128);
|
}
|
|
mem_heap_allocator<upd_node_t*> mem_heap_ator(node->cascade_heap);
|
|
cascade_upd_nodes = new |
(mem_heap_ator.allocate(sizeof(upd_cascade_t))) |
upd_cascade_t(deque_mem_heap_t(mem_heap_ator));
|
|
new_upd_nodes = new |
(mem_heap_ator.allocate(sizeof(upd_cascade_t))) |
upd_cascade_t(deque_mem_heap_t(mem_heap_ator));
|
|
processed_cascades = new |
(mem_heap_ator.allocate(sizeof(upd_cascade_t))) |
upd_cascade_t(deque_mem_heap_t(mem_heap_ator));
|
If the mem_heap_create(128) was replaced with a larger parameter, then these allocations could reuse the same memory heap for every updated row. It would still be unnecessary to allocate the memory when there are no FOREIGN KEY ON (UPDATE|DELETE) (SET NULL|CASCADE) constraints, but we would avoid the multiple calls to mem_heap_create_block_func() on every updated row.
Attachments
Issue Links
- is blocked by
-
MDEV-15219 FOREIGN KEY CASCADE or SET NULL operations will not resume after lock wait
- Closed
- is duplicated by
-
MDEV-15199 Triangular FKs - Cascade delete causes broken referential integrity
- Closed
- relates to
-
MDEV-14958 Merge new release of InnoDB MySQL 5.7.21 to 10.2
- Closed
-
MDEV-15611 Due to the failure of foreign key detection, Galera slave node killed himself.
- Closed