• MySQL Build Team's avatar
    Backport into build-200911241145-5.1.40sp1 · d301f60f
    MySQL Build Team authored
    > ------------------------------------------------------------
    > revno: 3190 [merge]
    > revision-id: kostja@sun.com-20091103174552-bfpak6r7ngf5cbjb
    > parent: magnus.blaudd@sun.com-20091103170719-6b64sjnivsiyz6xy
    > parent: kostja@sun.com-20091103165854-7di545xruez8w207
    > committer: Konstantin Osipov <kostja@sun.com>
    > branch nick: 5.1-41756
    > timestamp: Tue 2009-11-03 20:45:52 +0300
    > message:
    >   A fix and a test case for 
    >   Bug#41756 "Strange error messages about locks from InnoDB".
    >         
    >   In JT_EQ_REF (join_read_key()) access method, 
    >   don't try to unlock rows in the handler, unless certain that 
    >   a) they were locked
    >   b) they are not used.
    >   
    >   Unlocking of rows is done by the logic of the nested join loop,
    >   and is unaware of the possible caching that the access method may
    >   have. This could lead to double unlocking, when a row
    >   was unlocked first after reading into the cache, and then 
    >   when taken from cache, as well as to unlocking of rows which
    >   were actually used (but taken from cache).
    >         
    >   Delegate part of the unlocking logic to the access method,
    >   and in JT_EQ_REF count how many times a record was actually 
    >   used in the join. Unlock it only if it's usage count is 0.
    >   
    >   Implemented review comments.
    > ------------------------------------------------------------
    > Use --include-merges or -n0 to see merged revisions.
    d301f60f
sql_select.cc 537 KB