List:Commits« Previous MessageNext Message »
From:Kristofer Pettersson Date:April 1 2009 3:41pm
Subject:bzr commit into mysql-5.1-bugteam branch (kristofer.pettersson:2823)
View as plain text  
#At file:///home/thek/Development/cpp/mysqlbzr/51-bug43748/ based on revid:kristofer.pettersson@stripped

 2823 Kristofer Pettersson	2009-04-01
      Bug#43758 Query cache can lock up threads in 'freeing items' state
      Early patch submitted for discussion.
      It is possible for more than one thread to enter the condition
      in query_cache_insert(), but the condition predicate is to
      signal one thread each time the cache status changes between
      the following states: {NO_FLUSH_IN_PROGRESS,FLUSH_IN_PROGRESS,
      Consider three threads THD1, THD2, THD3
      THD2: select ... => Got a writer in ::store_query
      THD3: select ... => Got a writer in ::store_query
      THD1: flush tables => qc status= FLUSH_IN_PROGRESS; 
                            new writers are blocked.
      THD2: select ... => Still got a writer and enters cond in
      THD3: select ... => Still got a writer and enters cond in
      THD1: flush tables => finished and signal status change.
      THD2: select ... => Wakes up and completes the insert.
      THD3: select ... => Happily waiting for better times. Why hurry?
      A solution to this situation is to use a broadcast on the thread
      group which contain result set writers.
      Note about the test case:
      * If the thread policy in Query_cache::wait_while_flush_is_in_progress
        is set to RELEASE_ONE_ON_EACH_SIGNAL then the test case will hang.
        This should show the existence of a problem before the patch.
      * Two thread groups used to avoid using broadcast where it isn't needed.
        If it worth having two groups? Is substituting signal for broadcast enough?

Attachment: [text/bzr-bundle] bzr/
bzr commit into mysql-5.1-bugteam branch (kristofer.pettersson:2823)Bug#43758Kristofer Pettersson1 Apr