Skip to content

Conversation

@morrySnow
Copy link
Contributor

@morrySnow morrySnow commented Dec 19, 2024

pick from master #45045

Problem Summary:

Doris's table locks are fair read-write locks. If two threads acquire read locks on tables in different orders and simultaneously a third thread attempts to acquire a write lock on one of these tables, a deadlock can form between the two threads trying to acquire read locks. This PR changes the lock acquisition order for queries to follow the order of table IDs, ensuring that the lock acquisition order for tables is consistent among different threads.

Execute table locking operations in ascending order of table IDs

Problem Summary:

Doris's table locks are fair read-write locks. If two threads acquire
read locks on tables in different orders and simultaneously a third
thread attempts to acquire a write lock on one of these tables, a
deadlock can form between the two threads trying to acquire read locks.
This PR changes the lock acquisition order for queries to follow the
order of table IDs, ensuring that the lock acquisition order for tables
is consistent among different threads.

Execute table locking operations in ascending order of table IDs
@Thearas
Copy link
Contributor

Thearas commented Dec 19, 2024

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@morrySnow
Copy link
Contributor Author

run buildall

@morrySnow morrySnow merged commit afb59f5 into apache:branch-2.1 Dec 20, 2024
23 of 24 checks passed
@morrySnow morrySnow deleted the 2.1_45045 branch December 20, 2024 03:02
morrySnow pushed a commit that referenced this pull request Sep 16, 2025
…add ut test (#52601)

### What problem does this PR solve?

1. Nereids Translate Time should be after method
`PhysicalPlanTranslator#translatePlan`
2. fix 2.1 and 3.0 `Parse SQL Time` and `Nereids Lock Table Time` has
the same parseSqlStartTime.

Related PR: #39670 #45679
seawinde added a commit to seawinde/doris that referenced this pull request Nov 19, 2025
…add ut test (apache#52601)

1. Nereids Translate Time should be after method
`PhysicalPlanTranslator#translatePlan`
2. fix 2.1 and 3.0 `Parse SQL Time` and `Nereids Lock Table Time` has
the same parseSqlStartTime.

Related PR: apache#39670 apache#45679
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants