Uh oh!
There was an error while loading. Please reload this page.
[opt](Nereids) lock table in ascending order of table IDs - #45045
Merged
Conversation
doris-robot
commented
Dec 5, 2024
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
morrySnowforce-pushed
the
lock_table_by_id
branch
from
December 5, 2024 10:07
32b4505 to
37a00a2ComparemorrySnow
commented
Dec 5, 2024
ContributorAuthor
run buildall |
doris-robot
commented
Dec 5, 2024
TPC-H: Total hot run time: 39817 ms |
doris-robot
commented
Dec 5, 2024
TPC-DS: Total hot run time: 68792 ms |
doris-robot
commented
Dec 5, 2024
ClickBench: Total hot run time: 32.24 s |
morrySnowforce-pushed
the
lock_table_by_id
branch
2 times, most recently
from
December 5, 2024 11:13
aa00351 to
d030993ComparemorrySnow
commented
Dec 5, 2024
ContributorAuthor
run buildall |
morrySnowforce-pushed
the
lock_table_by_id
branch
from
December 5, 2024 15:02
d030993 to
c50ff85ComparemorrySnow
commented
Dec 5, 2024
ContributorAuthor
run buildall |
doris-robot
commented
Dec 5, 2024
TPC-H: Total hot run time: 39865 ms |
doris-robot
commented
Dec 5, 2024
TPC-DS: Total hot run time: 197793 ms |
doris-robot
commented
Dec 5, 2024
ClickBench: Total hot run time: 33.51 s |
morrySnowforce-pushed
the
lock_table_by_id
branch
from
December 5, 2024 17:07
c50ff85 to
fd02503ComparemorrySnow
commented
Dec 5, 2024
ContributorAuthor
run buildall |
doris-robot
commented
Dec 5, 2024
TPC-H: Total hot run time: 39926 ms |
doris-robot
commented
Dec 5, 2024
TPC-DS: Total hot run time: 196875 ms |
doris-robot
commented
Dec 5, 2024
ClickBench: Total hot run time: 32.59 s |
morrySnowforce-pushed
the
lock_table_by_id
branch
from
December 6, 2024 04:13
fd02503 to
47a8e07ComparemorrySnow
commented
Dec 6, 2024
ContributorAuthor
run buildall |
doris-robot
commented
Dec 6, 2024
TPC-H: Total hot run time: 39999 ms |
doris-robot
commented
Dec 6, 2024
TPC-DS: Total hot run time: 196928 ms |
doris-robot
commented
Dec 6, 2024
ClickBench: Total hot run time: 33.76 s |
morrySnowforce-pushed
the
lock_table_by_id
branch
from
December 6, 2024 09:38
47a8e07 to
888e041ComparemorrySnow
commented
Dec 6, 2024
ContributorAuthor
run buildall |
doris-robot
commented
Dec 6, 2024
TPC-H: Total hot run time: 39842 ms |
doris-robot
commented
Dec 6, 2024
TPC-DS: Total hot run time: 196897 ms |
doris-robot
commented
Dec 6, 2024
ClickBench: Total hot run time: 32.01 s |
morrySnowforce-pushed
the
lock_table_by_id
branch
from
December 7, 2024 03:53
888e041 to
5644491ComparemorrySnow added a commit
to morrySnow/incubator-doris
that referenced
this pull request
Dec 19, 2024
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
morrySnow added a commit
to morrySnow/incubator-doris
that referenced
this pull request
Dec 19, 2024
pick from master apache#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
16 tasks
morrySnow added a commit
that referenced
this pull request
Dec 20, 2024
morrySnow added a commit
that referenced
this pull request
Dec 20, 2024
16 tasks
morrySnow pushed a commit
that referenced
this pull request
Dec 24, 2024
…some test (#45744) ### What problem does this PR solve? Related PR: #45045 Problem Summary: if mv2 sql contains mv1 as following, if drop mv_level_1, query mv2 directly would cause err, this fix this CREATE MATERIALIZED VIEW mv2 BUILD IMMEDIATE REFRESH COMPLETE ON MANUAL DISTRIBUTED BY RANDOM BUCKETS 2 PROPERTIES ('replication_num' = '1') AS SELECT * FROM mv_level_1;
github-actionsBot
pushed a commit
that referenced
this pull request
Dec 24, 2024
…some test (#45744) ### What problem does this PR solve? Related PR: #45045 Problem Summary: if mv2 sql contains mv1 as following, if drop mv_level_1, query mv2 directly would cause err, this fix this CREATE MATERIALIZED VIEW mv2 BUILD IMMEDIATE REFRESH COMPLETE ON MANUAL DISTRIBUTED BY RANDOM BUCKETS 2 PROPERTIES ('replication_num' = '1') AS SELECT * FROM mv_level_1;
seawinde added a commit
to seawinde/doris
that referenced
this pull request
Dec 24, 2024
…some test (apache#45744) Related PR: apache#45045 Problem Summary: if mv2 sql contains mv1 as following, if drop mv_level_1, query mv2 directly would cause err, this fix this CREATE MATERIALIZED VIEW mv2 BUILD IMMEDIATE REFRESH COMPLETE ON MANUAL DISTRIBUTED BY RANDOM BUCKETS 2 PROPERTIES ('replication_num' = '1') AS SELECT * FROM mv_level_1;
16 tasks
morrySnow added a commit
that referenced
this pull request
Jan 7, 2025
16 tasks
morrySnow added a commit
that referenced
this pull request
Jan 16, 2025
### What problem does this PR solve? Related PR: #45045 Problem Summary: we get target table twice, lock them all
morrySnow added a commit
to morrySnow/incubator-doris
that referenced
this pull request
Jan 17, 2025
pick from master apache#47033 Related PR: apache#45045 Problem Summary: we get target table twice, lock them all
github-actionsBot
pushed a commit
that referenced
this pull request
Jan 17, 2025
### What problem does this PR solve? Related PR: #45045 Problem Summary: we get target table twice, lock them all
Closed
16 tasks
morrySnow added a commit
that referenced
this pull request
Jan 24, 2025
…the original target table (#47337) ### What problem does this PR solve? Related PR: #47033#45045 Problem Summary: because schema change does not involve recreating the table object, but rather rebuilding the full schema. So, we should use the schema saved during planning as the schema of the original target table.
16 tasks
16 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What problem does this PR solve?
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.
Release note
Execute table locking operations in ascending order of table IDs
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)