summaryrefslogtreecommitdiff
path: root/sql/rpl_rli.h
diff options
context:
space:
mode:
authorDavi Arnaut <Davi.Arnaut@Sun.COM>2009-04-03 16:11:54 -0300
committerDavi Arnaut <Davi.Arnaut@Sun.COM>2009-04-03 16:11:54 -0300
commitaebaf079d1611532767dd0c9b183ca73a07b6ac9 (patch)
treeb11bced0612f7135d287c919aace0baf06344d69 /sql/rpl_rli.h
parent668d988c71a7980b3f131feb51c24427cfd78082 (diff)
downloadmariadb-git-aebaf079d1611532767dd0c9b183ca73a07b6ac9.tar.gz
Bug#43230: SELECT ... FOR UPDATE can hang with FLUSH TABLES WITH READ LOCK indefinitely
The problem is that a SELECT .. FOR UPDATE statement might open a table and later wait for a impeding global read lock without noticing whether it is holding a table that is being waited upon the the flush phase of the process that took the global read lock. The same problem also affected the following statements: LOCK TABLES .. WRITE UPDATE .. SET (update and multi-table update) TRUNCATE TABLE .. LOAD DATA .. The solution is to make the above statements wait for a impending global read lock before opening the tables. If there is no impending global read lock, the statement raises a temporary protection against global read locks and progresses smoothly towards completion. Important notice: the patch does not try to address all possible cases, only those which are common and can be fixed unintrusively enough for 5.0.
Diffstat (limited to 'sql/rpl_rli.h')
0 files changed, 0 insertions, 0 deletions