Endless loop after innodb_adaptive_hash_index is turned off

[林晓斌]

When set innodb_adaptive_hash_index_partitions >1, the logic in btr_search_drop_page_hash_index will lead to endless loop .
After set innodb_adaptive_hash_index = off, the blok->index is set to NULL but block->btr_search_latch not reset.

Repeat :

set innodb_adaptive_hash_index_partitions = 8
innodb_buffer_pool_size = 32M

source
 http://www.mysqlops.com/wp-content/uploads/2013/03/ahi_loop1.txt

suggest fix:
  set block->btr_search_latch to NULL when "buf_pool_clear_hash_index"

[Raghavendra D Prabhu (raghavendra-prabhu)]

I am able to confirm the issue and it seems to be stuck in one of
those retry loops in btr_search_drop_page_hash_index.

Along with suggested fix, it may also be better to check if
btr_search_enabled is true in btr_free_root before dropping the
page hash index.

Note, both the size of buffer pool and number of partitions
matter for reproduction. For larger buffer pools, you need to
load it significantly more.

I have got the backtraces as well which I will attach in the next
comment.

[Raghavendra D Prabhu (raghavendra-prabhu)]

GDB backtraces. - thread apply all bt and thread apply all bt full

[Raghavendra D Prabhu (raghavendra-prabhu)]

Also, even though upstream version has similar behavior in buf_pool_clear_hash_index, since multiple adaptive hash partitions are not present in upstream, that bug is not present in btr_search_drop_page_hash_index (even for PS, having AHI partitions to 1 should do).

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-2918