[Fix] join_table_handler break insert select into two queries to avoid deadlock #11
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Make sure these boxes checked before submitting your pull request.
For significant changes like big bug fixes, new features, please open an issue to make an agreement on an implementation design/plan first before starting it.
What did this pull request do?
The join_table_handler uses
INSERT INTO TABLE ... NO EXIST (SELECT FROM TABLE)
query to do the mapping table checking and insert record in one statement. This query would try to acquire IX (insert intent exclusive lock by insert part) and S (share lock by select part). At concurrent scenario, this would lead to deadlock between transactions.This PR changes the join_table_handler logic by breaking the statement into two. The first part do the
SELECT FOR UPDATE
orSELECT
for sqlite3 check whether there is the mapping record, as it will hold necessary lock first and avoid another transaction contending.Below is an example to reproduce deadlock manually using join_table_handler generated SQL:
Please kindly help review this PR