[fix](schema-change) reset table state when cancelling a job stuck in WAITING_STABLE - #66178
Open
Baymine wants to merge 1 commit into
Open
[fix](schema-change) reset table state when cancelling a job stuck in WAITING_STABLE#66178Baymine wants to merge 1 commit into
Baymine wants to merge 1 commit into
Conversation
… WAITING_STABLE What problem does this PR solve? Issue Number: close apache#66177 Problem Summary: When a schema-change job is cancelled while the table is still in the WAITING_STABLE sub-state (the table never became stable, so the job was never promoted to SCHEMA_CHANGE), the table state was not reset back to NORMAL: SchemaChangeJobV2.changeTableState only reset from SCHEMA_CHANGE. The table was then permanently stuck in WAITING_STABLE with no live job, and every subsequent ALTER / TRUNCATE / DROP PARTITION / RENAME / CANCEL was rejected -- the only escape was DROP TABLE. This fixes it in two places: 1. SchemaChangeJobV2.changeTableState now also resets the table from WAITING_STABLE (not just SCHEMA_CHANGE) when a job is cancelled, so the normal "cancel a WAITING_STABLE job" path returns the table to NORMAL. 2. SchemaChangeHandler.cancelColumnJob now self-heals a table left in an orphaned WAITING_STABLE state with no backing job (which older binaries could produce) by resetting it to NORMAL durably via setTableStatusInternal, instead of throwing "could not find related job". An orphaned SCHEMA_CHANGE state (not a known-reachable state) still fails loudly so it is investigated rather than silently masked. Release note: Fix a schema-change table state leak: cancelling a job that is stuck in WAITING_STABLE now correctly resets the table to NORMAL instead of leaving it permanently blocked for all subsequent ALTER operations. Check List (For author) - [x] Test <!-- At least one of them must be included. --> - [ ] Regression test - [x] Unit Test - [ ] Manual test (add detailed scripts or steps below) - [ ] No need for documentation
Contributor
Author
|
run buildall |
Contributor
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
3 tasks
Contributor
FE UT Coverage ReportIncrement line coverage |
Contributor
TPC-H: Total hot run time: 29535 ms |
Contributor
TPC-DS: Total hot run time: 178497 ms |
Contributor
ClickBench: Total hot run time: 25.01 s |
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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?
Issue Number: close #66177
Related PR: N/A
Problem Summary:
When a schema-change job is cancelled while the table is still in the
WAITING_STABLEsub-state (the table never became stable, so the job was never promoted toSCHEMA_CHANGE), the table state was not reset back toNORMAL:SchemaChangeJobV2.changeTableStateonly reset fromSCHEMA_CHANGE. The table was then permanently stuck inWAITING_STABLEwith no live job, and every subsequent ALTER / TRUNCATE / DROP PARTITION / RENAME / CANCEL was rejected — the only escape was DROP TABLE.This fixes it in two places:
SchemaChangeJobV2.changeTableStatenow also resets the table fromWAITING_STABLE(not justSCHEMA_CHANGE) when a job is cancelled, so the normal "cancel a WAITING_STABLE job" path returns the table toNORMAL.SchemaChangeHandler.cancelColumnJobnow self-heals a table left in an orphanedWAITING_STABLEstate with no backing job (which older binaries could produce) by resetting it toNORMALdurably viasetTableStatusInternal, instead of throwing "could not find related job". An orphanedSCHEMA_CHANGEstate (not a known-reachable state) still fails loudly so it is investigated rather than silently masked.Release note
Fix a schema-change table state leak: cancelling a job that is stuck in WAITING_STABLE now correctly resets the table to NORMAL instead of leaving it permanently blocked for all subsequent ALTER operations.
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)