ddl: Do not succee the last_gc_safepoint when physically dropping table is skipped (#8910) #8913
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.
This is an automated cherry-pick of #8910
What problem does this PR solve?
Issue Number: close #8911
Problem Summary:
In #8721, we introduce a rule that: "if the regions of a given table is not totally removed from TiFlash, skip physically dropping it". However, it does not set the succeeded = false, so after all it will update the last_gc_safepoint.
When the whole cluster has few write commands, the gc_safepoint may not change. It make that the physically dropping only run after the gc_safepoint is changed again. Which will slow down the data disk reclaim.
What is changed and how it works?
succeeded = false
last_gc_safepoint
will not get updatedddl_sync_interval_seconds
passed,SchemaSyncService::gc
will run again even if thegc_safepoint
on PD side is not changedCheck List
Tests
Side effects
Documentation
Release note