-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
InnoDB deadlock between cuncurrent lock/unlock in Minion #38
Comments
Unfortunately READ-COMMITTED doesn't help in all cases and I am getting another deadlock between concurrent lock() commands:
So I've submitted #40 |
Please also refer about behavior of autocommit in stored functions: https://jira.mariadb.org/browse/MDEV-31108 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am seeing this deadlock frequently (some lines are removed):
Note that lock names are different in both transactions.
After some research I concluded that such behavior is a flaw in InnoDB and described in https://bugs.mysql.com/bug.php?id=25847
So, switching isolation level to READ-COMMITTED should be proper workaround for my case.
But I think the lib should remove DELETE command from stored function minion_lock(). Because currently the locks from DELETE are held longer than needed (i.e. until INSERT is committed). Instead, call the DELETE statement explicitly from perl code.
The text was updated successfully, but these errors were encountered: