ddl: Fix logging cause by non-dropped table#8955
ddl: Fix logging cause by non-dropped table#8955ti-chi-bot[bot] merged 5 commits intopingcap:masterfrom
Conversation
|
/run-all-tests |
|
/run-unit-test |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: JinheLin, Lloyd-Pottiger The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
[LGTM Timeline notifier]Timeline:
|
|
@JaySon-Huang: Your PR was out of date, I have automatically updated it for you. At the same time I will also trigger all tests for you: /run-all-tests
If the CI test fails, you just re-trigger the test that failed and the bot will merge the PR for you after the CI passes. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository. |
|
/run-unit-test |
|
In response to a cherrypick label: new pull request created to branch |
|
In response to a cherrypick label: new pull request created to branch |
What problem does this PR solve?
Issue Number: close #8911
Problem Summary:
After #8910, if some tables are not able to be dropped,
SchemaSyncService::gcImplwill run again with the same gc_safepoint.But in this path,
SchemaSyncService::gcImplalways return true. So if there are some tables can not be dropped for some bugs, then this function will run again and again and print lots of loggings.What is changed and how it works?
if
succeeded == false, then letSchemaSyncService::gcImplrun again afterddl_sync_interval_secondsCheck List
Tests
Side effects
Documentation
Release note