Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.2.27
-
None
-
Linux
Description
The issue originally manifested as INSERTs into a small table with a primary key and a unique key taking a long time due to frequent deadlocks in production. We have not yet been able to reproduce it in a test environment. However, we have been able to grab mysqld from the problematic state and explore it.
To facilitate the exploration of the core I wrote a Python module to be used with GDB where I ported some common InnoDB routines to Python so we can examine complex InnoDB data structures (https://github.com/spachev/python-innodb-gdb).
Unfortunately, I am not able to publicly share the core. However, I can report that by calling innodb_gdb.print_trx_locks() I see that one of the transactions is holding 200+ shared record locks on various unique index entries with different values of the primary key while trying to obtain an exclusive lock on the same index with the same value for the unique. I have verified that the connection at the time was in AUTOCOMMIT mode and no BEGIN or other transaction starting statements were issued by checking the appropriate flags in thd.
Is this a bug, or is there potentially a legitimate use case when you could get this to happen while inserting just one record?