airborne12 opened a new pull request, #69443:
URL: https://github.com/apache/doris/pull/69443

   ### What problem does this PR solve?
   
   Issue Number: None
   
   Related PR: #68674
   
   Problem Summary:
   
   In local (non-cloud) mode, an unfinished index change job only conflicts 
with a new one on the same partition when both go in the same direction. An 
unfinished `BUILD INDEX idx` therefore does not block `DROP INDEX idx` 
(full-table or `PARTITION`), and an unfinished `DROP INDEX idx PARTITION (p)` 
does not block `BUILD INDEX idx` on `p`:
   
   ```sql
   BUILD INDEX idx_v1 ON t;           -- the job is still running
   ALTER TABLE t DROP INDEX idx_v1;   -- accepted
   ```
   
   The two jobs are submitted to the schema change thread pool independently, 
and the BE tablet locks only make them mutually exclusive, not ordered. If the 
build runs after the drop, it writes `idx_v1` back into the rowsets, although 
the table metadata no longer has that index (or, for the opposite order, the 
index the user just built is deleted again). Cloud mode already treats any 
unfinished job on the partition as a conflict.
   
   Root cause: `SchemaChangeHandler#hasIndexChangeJobOnPartition` matches 
existing jobs in local mode with 
`IndexChangeJob#hasSameAlterInvertedIndex(isDrop, indexes)`, which only reports 
a job of the same direction.
   
   Fix: `IndexChangeJob#hasAlterInvertedIndex(indexes)` matches a job that 
builds or drops any of the indexes, in either direction, and 
`hasIndexChangeJobOnPartition` drops its direction parameter. The light `DROP 
INDEX` pre-check, `DROP INDEX ... PARTITION` and `BUILD INDEX` all use this 
check, so each of them is rejected while a job of the same index is unfinished 
on the partition, with the existing error message; it can be retried once the 
job finishes.
   
   ### Release note
   
   In non-cloud mode, `DROP INDEX` and `BUILD INDEX` are rejected while an 
index change job of the same index in the other direction is unfinished on the 
partition, instead of running both jobs in no particular order.
   
   ### Check List (For Author)
   
   - Test <!-- At least one of them must be included. -->
       - [ ] Regression test
       - [x] Unit Test
       - [ ] Manual test (add detailed scripts or steps below)
       - [ ] No need to test or manual test. Explain why:
           - [ ] This is a refactor/code format and no logic has been changed.
           - [ ] Previous test can cover this change.
           - [ ] No code files have been changed.
           - [ ] Other reason <!-- Add your reason?  -->
   
     `SchemaChangeHandlerTest#testDropIndexRejectedByPendingBuildOfSameIndex` 
registers an unfinished build job of `idx_v1` on `p1` (in `indexChangeJobs` 
only, so the scheduler cannot cancel it), checks that `DROP INDEX idx_v1` and 
`DROP INDEX idx_v1 PARTITION (p1)` are rejected and keep the index, then that 
the drop succeeds once the job is FINISHED. The test fails without the change.
   
   - Behavior changed:
       - [ ] No.
       - [x] Yes. <!-- Explain the behavior change -->
         In non-cloud mode an unfinished index change job conflicts with a new 
job of the same index on the same partition in either direction.
   
   - Does this need documentation?
       - [x] No.
       - [ ] Yes. <!-- Add document PR link here. eg: 
https://github.com/apache/doris-website/pull/1214 -->
   
   ### Check List (For Reviewer who merge this PR)
   
   - [ ] Confirm the release note
   - [ ] Confirm test cases
   - [ ] Confirm document
   - [ ] Add branch pick label <!-- Add branch pick label that this PR should 
merge into -->
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to