-
Notifications
You must be signed in to change notification settings - Fork 727
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Potential Bug: Tables Undergoing Vacuum Process Can Be Improperly Undropped #16433
Comments
Thanks to @SkyFan2002 for identifying this issue. |
Hey @drmingdrmer, I'm here to help you with any bugs, questions, or contributions you have. Let's get this sorted together! Dosu To address the issue of undropping tables that have undergone or are undergoing the vacuum process, you can introduce a Proposed Changes
By implementing these changes, you can effectively prevent the undropping of tables that are undergoing or have completed the vacuum process, thus maintaining data consistency and preventing potential data loss [1][2]. |
If `gc_in_progress` is set, no un-drop can be done on this database. Because the related data may already have been deleted. This commit does not use this flag yet, and will be used in next commit. - Part of datafuselabs#16433
If `gc_in_progress` is set, no un-drop can be done on this database. Because the related data may already have been deleted. This commit does not use this flag yet, and will be used in next commit. - Part of datafuselabs#16433
If `gc_in_progress` is set, no un-drop can be done on this database. Because the related data may already have been deleted. This commit does not use this flag yet, and will be used in next commit. - Part of datafuselabs#16433
If `gc_in_progress` is set, no un-drop can be done on this database. Because the related data may already have been deleted. This commit does not use this flag yet, and will be used in next commit. - Part of datafuselabs#16433
If `gc_in_progress` is set, no un-drop can be done on this database. Because the related data may already have been deleted. This commit does not use this flag yet, and will be used in next commit. - Part of datafuselabs#16433
If `gc_in_progress` is set, no un-drop can be done on this database. Because the related data may already have been deleted. This commit does not use this flag yet, and will be used in next commit. - Part of datafuselabs#16433
If `gc_in_progress` is set, no un-drop can be done on this database. Because the related data may already have been deleted. This commit does not use this flag yet, and will be used in next commit. - Part of datafuselabs#16433
* refactor: add DatabaseMeta.gc_in_progress If `gc_in_progress` is set, no un-drop can be done on this database. Because the related data may already have been deleted. This commit does not use this flag yet, and will be used in next commit. - Part of #16433 * chore: fix up proto tests version: 109->110
Current Behavior
When vacuuming a table, the following sequence occurs:
However, the current API allows undropping of a dropped table even after its S3 data has been purged, leading to potential data inconsistency.
Impact
This bug can result in: Data loss: Undropping a table with purged S3 data creates an empty table.
Proposed Solution
Introduce a
vacuum_status
flag in theTableMeta
structure to prevent undropping of tables undergoing or having completed the vacuum process.Revised State Transition Flow:
The text was updated successfully, but these errors were encountered: