diff options
author | Davi Arnaut <Davi.Arnaut@Sun.COM> | 2009-04-03 16:11:54 -0300 |
---|---|---|
committer | Davi Arnaut <Davi.Arnaut@Sun.COM> | 2009-04-03 16:11:54 -0300 |
commit | aebaf079d1611532767dd0c9b183ca73a07b6ac9 (patch) | |
tree | b11bced0612f7135d287c919aace0baf06344d69 /sql/rpl_rli.h | |
parent | 668d988c71a7980b3f131feb51c24427cfd78082 (diff) | |
download | mariadb-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