| Bug #113889 | Lock is not released when thread is killed | ||
|---|---|---|---|
| Submitted: | 4 Feb 2024 6:17 | Modified: | 5 Feb 2024 11:08 |
| Reporter: | Salman Ali | Email Updates: | |
| Status: | Can't repeat | Impact on me: | |
| Category: | MySQL Server: Locking | Severity: | S3 (Non-critical) |
| Version: | OS: | Any | |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | locking, PROCESSLIST, threads, xa_transactions | ||
[4 Feb 2024 6:22]
Salman Ali
UPDATE: I just tested it out for normal transactions and there is no issues. This issue exists for the XA transactions only after PREPARE statement.
steps are the same with one difference:
- After the insert is done
- Execute XA PREPARE {xid}
- Kill processId
[5 Feb 2024 11:08]
MySQL Verification Team
Hi Mr. Ali, Thank you for your bug report. However, we were not able to repeat your report. We did use XA transactions and it all worked find. Also, we need to know how exactly have you concluded that the lock that mapped to the same thread is not deleted and it's stuck `data_locks`. Next, we do not see whether you have killed a running query or the entire connection. Next, your "Category" seems to be wrong. Are you sure that it is about "Locking" or "XA transactions" ??? Last, but not leas, you have not specified whether you kill a query or the connection. Hence, what we require is a fully repeatable test case, that we shall be able to repeat on our own 8.0.36 binary. Can't repeat.
Description: When execute KILL {processId} it deletes the process and its thread and the current statements linked to it as well on `performance_schema`. But the lock that mapped to the same thread is not deleted and it's stuck `data_locks`. How to repeat: - Connect to the DB - Do some insert query (to add the lock) - Execute `Kill processId` linked to that lock Why I'm killing processes manually in the first place? - it's a worker used to timeout old connections Suggested fix: Use a foreign key with on delete cascade for the `threads` table and `data_locks` and `metadata_locks` tables in `performance_schama`, so there will be no leftovers once the thread is killed.