Skip to content
  • Ole John's avatar
    2ad5e1ac
    Bug#23553267 DEADLOCK WHEN MDL_EXCLUSIVE ACQUIRES A GLOBAL SCHEMA LOCK (GSL) · 2ad5e1ac
    Ole John authored
    Cherry pick of the server part of the patch from mysql-5.7
    In adition this commit adds the Cluster specific part of patch
    
    NdbCluster code for acquiring a Global Schema Lock has been changed
    to not retry the GSL lock if it failed due to a timeout (default 3000ms),
    *and* there is a potential for this lock request participating in a MDL-GSL
    deadlock. In these cases it select itself as a 'victim', and return
    this decission to the MDL requestor.
    
    MDL code will then either handle such a victimized GSL request either as
    a failed lock request - Which is better than staying in a deadlock state
    forever.
    
    Or, where a deadlock_handler exist in the MDL code, it will backof
    and retry the MDL+GSL locking again. (Valid for CREATE TABLE which
    was the soure for the deadlocks in the attached test case)
    2ad5e1ac
    Bug#23553267 DEADLOCK WHEN MDL_EXCLUSIVE ACQUIRES A GLOBAL SCHEMA LOCK (GSL)
    Ole John authored
    Cherry pick of the server part of the patch from mysql-5.7
    In adition this commit adds the Cluster specific part of patch
    
    NdbCluster code for acquiring a Global Schema Lock has been changed
    to not retry the GSL lock if it failed due to a timeout (default 3000ms),
    *and* there is a potential for this lock request participating in a MDL-GSL
    deadlock. In these cases it select itself as a 'victim', and return
    this decission to the MDL requestor.
    
    MDL code will then either handle such a victimized GSL request either as
    a failed lock request - Which is better than staying in a deadlock state
    forever.
    
    Or, where a deadlock_handler exist in the MDL code, it will backof
    and retry the MDL+GSL locking again. (Valid for CREATE TABLE which
    was the soure for the deadlocks in the attached test case)
Loading