sql: mark index as GCed if table has been GCed in legacy gc path #99888
Conversation
|
This change is |
chengxiong-ruan
added
backport-23.1.x
There was a problem hiding this comment.
Reviewed 3 of 3 files at r1.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @chengxiong-ruan)
-- commits line 17 at r1:
I think you should update the release note to say something also about dropped indexes. Also, don't say anything about DelRange, folks don't know what this is, and we don't really document it much. It's fine to not tell people about the edge case (they flipped un undocumented cluster setting) that might have made the bug not apply.
|
nit: I think this should be marked as a bug fix in the release note, rather than a SQL change. |
Previously, if a table is GCed before an index is GCed by a TRUNCATE TABLE gc job, the TRUNCATE TABLE gc job can be stuck in running status because the table descriptor is missing. This is problematic because these jobs will never succeed and doing nothing. This commit marks the indexes as GCed if the descriptor cannot be found assuming that the table has been GCed. Also, table GC should have GCed all the indexes. Note that this only affect the legacy GC path. Epic: None Release note (bug fix): This commit fixes a bug where TRUNCATE TABLE gc job can be stuck in running status if the table descriptor has been GCed. It was because TRUNCATE TABLE actually creates new empty indexes, then replaces and drops the old indexes. The dropped indexes data are deleted and GCed within the TRUNCATE TABLE gc job which needed to see the table descriptor to make progress. But, if the table data has been GCed, the TRUNCATE TABLE gc job couldn't make progress. This patch makes it able to handle the missing descriptor edge case and let the TRUNCATE TABLE gc job succeed.
chengxiong-ruan
force-pushed
the
mark-index-gced-if-table-gced
branch
from
9f623c7 to
a22ef53
Compare
|
I've updated the release. Thanks for the good calls. |
|
TFTR! |
|
Build succeeded: |
|
Encountered an error creating backports. Some common things that can go wrong:
You might need to create your backport manually using the backport tool. error creating merge commit from a22ef53 to blathers/backport-release-22.1-99888: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict [] you may need to manually resolve merge conflicts with the backport tool. Backport to branch 22.1.x failed. See errors above. error creating merge commit from a22ef53 to blathers/backport-release-22.2-99888: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict [] you may need to manually resolve merge conflicts with the backport tool. Backport to branch 22.2.x failed. See errors above. 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf. |
Previously, if a table is GCed before an index is GCed by a TRUNCATE TABLE gc job, the TRUNCATE TABLE gc job can be stuck in running status because the table descriptor is missing. This is problematic because these jobs will never succeed and doing nothing. This commit marks the indexes as GCed if the descriptor cannot be found assuming that the table has been GCed. Also, table GC should have GCed all the indexes.
Note that this only affect the legacy GC path.
Epic: None
Release note (bug fix): This commit fixes a bug where TRUNCATE TABLE gc job can be stuck in running status if table descriptor has been GCed before the truncated indexes are GCed. The bug was only a problem before
DelRangeis not available.