Bug #87812 Concurrent DDL operation in progress even after acquiring backup lock
Submitted: 20 Sep 2017 5:18 Modified: 5 Mar 14:25
Reporter: Debarun Banerjee Email Updates:
Status: Closed Impact on me:
Category:MySQL Server: Data Dictionary Severity:S3 (Non-critical)
Version:8.0.3 OS:Any
Assigned to: CPU Architecture:Any

[20 Sep 2017 5:18] Debarun Banerjee
While using service interface from "WL#9451:Backup Lock" from clone plugin, I observe that it could acquire "backup lock" successfully while concurrent DDL is still running.

This issue would impact both Clone and MEB.

How to repeat:
1. Stop DDL command "Drop Table" in fil_delete_tablespace() - Either in debugger or debug_sync

2. From another session do "LOCK INSTANCE FOR BACKUP"

Currently "Lock Instance" command finishes successfully, without waiting for the DDL to finish. 

Suggested fix:
Release Backup Lock only after DDL is complete.

We are releasing the backup lock in DDL too early ...


if (check_if_backup_lock_has_to_be_acquired(lex) &&
      acquire_shared_backup_lock(thd, thd->variables.lock_wait_timeout))

if (stmt_causes_implicit_commit(thd, CF_IMPLICIT_COMMIT_BEGIN))
    /* Release metadata locks acquired in this transaction. */

Since most DDL would implicitly commit the previous transaction (CF_IMPLICIT_COMMIT_BEGIN), the backup lock is getting released even before the DDL has started execution

bool acquire_shared_backup_lock(THD *thd, ulong lock_wait_timeout)
  return acquire_mdl_for_backup(thd, MDL_INTENTION_EXCLUSIVE, MDL_TRANSACTION,
The shared backup lock is taken for transaction duration
[5 Mar 14:25] Daniel Price
Posted by developer:
Fixed as of the upcoming 8.0.5 release, and here's the changelog entry:

A LOCK INSTANCE FOR BACKUP operation was able to acquire a backup lock
without wait for a concurrent DDL operation to finish.