> ------------------------------------------------------------
> 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.