BUG#21051: RESET QUERY CACHE very slow when query_cache_type=0

There were two problems: RESET QUERY CACHE took a long time to complete
and other threads were blocked during this time.

The patch does three things:
  1 fixes a bug with improper use of test-lock-test_again technique.
      AKA Double-Checked Locking is applicable here only in few places.
  2 Somewhat improves performance of RESET QUERY CACHE.
      Do my_hash_reset() instead of deleting elements one by one.  Note
      however that the slowdown also happens when inserting into sorted
      list of free blocks, should be rewritten using balanced tree.
  3 Makes RESET QUERY CACHE non-blocking.
      The patch adjusts the locking protocol of the query cache in the
      following way: it introduces a flag flush_in_progress, which is
      set when Query_cache::flush_cache() is in progress.  This call
      sets the flag on enter, and then releases the lock.  Every other
      call is able to acquire the lock, but does nothing if
      flush_in_progress is set (as if the query cache is disabled).
      The only exception is the concurrent calls to
      Query_cache::flush_cache(), that are blocked until the flush is
      over.  When leaving Query_cache::flush_cache(), the lock is
      acquired and the flag is reset, and one thread waiting on
      Query_cache::flush_cache() (if any) is notified that it may
      proceed.
This commit is contained in:
kroki/tomash@moonlight.intranet 2006-08-22 11:47:52 +04:00
commit 0f0ddc398a
5 changed files with 388 additions and 236 deletions

View file

@ -210,7 +210,13 @@ typedef struct st_net {
char last_error[MYSQL_ERRMSG_SIZE], sqlstate[SQLSTATE_LENGTH+1];
unsigned int last_errno;
unsigned char error;
/*
'query_cache_query' should be accessed only via query cache
functions and methods to maintain proper locking.
*/
gptr query_cache_query;
my_bool report_error; /* We should report error (we have unreported error) */
my_bool return_errno;
} NET;