• Jon Olav Hauglid's avatar
    Bug #47682 strange behaviour of INSERT DELAYED · a6733b52
    Jon Olav Hauglid authored
    The problem was a "self-deadlock" if the connection issuing INSERT DELAYED
    had both the global read lock (FLUSH TABLES WITH READ LOCK) and LOCK TABLES
    mode active. The table being inserted into had to be different from the 
    table(s) locked by LOCK TABLES.
    
    For INSERT DELAYED, the connection thread waits until the handler thread has
    opened and locked its table before returning. But since the global read lock
    was active, the handler thread would be unable to lock and would wait for the
    global read lock to go away.
    
    So the handler thread would be waiting for the connection thread to release
    the global read lock while the connection thread was waiting for the handler
    thread to lock the table. This gave a "self-deadlock" (same connection,
    different threads).
    
    The deadlock would only happen if we also had LOCK TABLES mode since the
    INSERT otherwise will try to get protection against global read lock before
    starting the handler thread. It will then notice that the global read lock
    is owned by the same connection and report ER_CANT_UPDATE_WITH_READLOCK.
    
    This patch removes the deadlock by reporting ER_CANT_UPDATE_WITH_READLOCK
    also if we are inside LOCK TABLES mode.
    
    Test case added to delayed.test.
    a6733b52
delayed.result 7.8 KB