mirror of
https://github.com/MariaDB/server.git
synced 2025-01-30 18:41:56 +01:00
8a86df37ef
A 3-thread deadlock has been frequently observed when using innodb_change_buffering!=none and innodb_file_per_table=0: (1) ibuf_merge_or_delete_for_page() holding an exclusive latch on the block and waiting for an exclusive tablespace latch in fseg_page_is_allocated() (2) btr_free_but_not_root() in fseg_free_step() waiting for an exclusive tablespace latch (3) fsp_alloc_free_page() holding the exclusive tablespace latch and waiting for a latch on the block, which it is reallocating for something else While this was reproduced using innodb_file_per_table=0, this hang should be theoretically possible in .ibd files as well, when the recovery or cleanup of a failed DROP INDEX or ADD INDEX is executing concurrently with something that involves page allocation. ibuf_merge_or_delete_for_page(): Avoid invoking fseg_page_is_allocated() when block==nullptr. The call was redundant in this case, and it could cause deadlocks due to latching order violation. ibuf_read_merge_pages(): Acquire an exclusive tablespace latch before invoking buf_page_get_gen(), which may cause fseg_page_is_allocated() to be invoked in ibuf_merge_or_delete_for_page(). Note: This will not fix all latching order violations in this area! Deadlocks involving ibuf_merge_or_delete_for_page(block!=nullptr) are still possible if the caller is not acquiring an exclusive tablespace latch upfront. This would be the case in any read operation that involves a change buffer merge, such as SELECT, CHECK TABLE, or any DML operation that cannot be buffered in the change buffer. |
||
|---|---|---|
| .. | ||
| archive | ||
| blackhole | ||
| columnstore | ||
| connect | ||
| csv | ||
| example | ||
| federated | ||
| federatedx | ||
| heap | ||
| innobase | ||
| maria | ||
| mroonga | ||
| myisam | ||
| myisammrg | ||
| oqgraph | ||
| perfschema | ||
| rocksdb | ||
| sequence | ||
| sphinx | ||
| spider | ||
| test_sql_discovery | ||