Bug#32149: Long semaphore wait for adaptive hash latch

Holding on to the temporary inno hash index latch is an optimization in
many cases, but a pessimization in some others.

Release temporary latches for those corner cases we (or rather, or customers,
thanks!) have identified, that is, when we are about to do something that
might take a really long time, like REPAIR or filesort.

sql/ha_myisam.cc:
  Let go of (inno, for now) latch when doing MyISAM-repair.
  (optimize passes through repair.) ("Stuck" in "Repair with
  keycache".)
sql/sql_insert.cc:
  Let go of (inno, for now) latch when doing CREATE...SELECT
  in select_insert::send_data() -- it might take a while.
  ("stuck" in "Sending data")
sql/sql_select.cc:
  Release temporary (inno, for now) latch on
  - free_tmp_table() (this can take surprisingly long, "removing tmp table")
  - create_myisam_from_heap() (HEAP table overflowing onto disk as MyISAM,
    "converting HEAP to MyISAM")

1 files changed, 3 insertions, 0 deletions

diff --git a/sql/sql_insert.cc b/sql/sql_insert.cc
index d9027e3f5b9..6d63a0907df 100644
--- a/sql/sql_insert.cc
+++ b/sql/sql_insert.cc
@@ -2935,6 +2935,9 @@ bool select_insert::send_data(List<Item> &values)
     }
   }
   
+  // Release latches in case bulk insert takes a long time
+  ha_release_temporary_latches(thd);
+
   error= write_record(thd, table, &info);
   table->auto_increment_field_not_null= FALSE;