Backport into build-200906240007-5.1.34sp1
> ------------------------------------------------------------ > revno: 2852.2.3 > revision-id: davi.arnaut@sun.com-20090403194600-60ufn0tz1gx1kl0l > parent: gni@mysql.com-20090403184200-vnjtpsv4an79w8bu > parent: davi.arnaut@sun.com-20090403191154-0ho2nai3chjsmpof > committer: Davi Arnaut <Davi.Arnaut@Sun.COM> > branch nick: 43230-5.1 > timestamp: Fri 2009-04-03 16:46:00 -0300 > message: > Merge Bug#43230 into mysql-5.1-bugteam > ------------------------------------------------------------ > revno: 1810.3855.16 > revision-id: davi.arnaut@sun.com-20090403191154-0ho2nai3chjsmpof > parent: chad@mysql.com-20090402152928-3ld60a56h86njcpg > committer: Davi Arnaut <Davi.Arnaut@Sun.COM> > branch nick: 43230-5.0 > timestamp: Fri 2009-04-03 16:11:54 -0300 > message: > 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.
Showing
Please register or sign in to comment