-
Notifications
You must be signed in to change notification settings - Fork 3.8k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
sql: correctly identify and cleanup dependent objects in drop database
There were a few things going on here because of the way we filtered tables during `DROP DATABASE CASCADE`. The intention was to filter out objects that depended on other objects also being deleted (and would therefore be deleted by the CASCADE nature of object drops). This assumption is correct for table-view and view-view dependencies -- but not for sequences. We also switched from individual schema change jobs during a database drop to a single job which doesn't play well with this filtering -- as no new jobs are queued, all objects that were filtered would leave orphaned namespace/descriptor entries behind. It's interesting to note that the filtering didn't directly cause this issue, it just made the underlying issue more visible -- the single drop database schema change job relies on knowing about all object descriptors that need to be dropped upfront. Orphaned entries which would have only occured for cross-database dependencies can occur in the same database because of the filtering. This leads to why the fix is what it is. As part of this patch, I've tried to make the preperation steps for dropping databases more explicit. First, we accumalate all objects that need to be deleted. This includes objects that will be implicitly deleted, such as owned sequences, dependent views (both in the database being deleted and other databases that aren't being deleted). The schema change job uses this new list to ensure entries are appropriately cleaned up. We still perform the filter step as before to identify objects which are the "root" of a drop and only call drop on these objects. The only change here is that instead of accumulating dependent objects, we explicitly accumulate cascading views. Fixes #51782 Fixes #50997 Release note (bug fix): Before this change, we would leave orphaned system.namespace/system.descriptor entries if we ran a `DROP DATABASE CASCADE` and the database contained "dependency" relations. For example, if the database included a view which depended on a table in the database, dropping the database would result in an orphaned entry for the view. Same thing for a sequence that was used by a table in the database. (See #51782 for repro steps). This bug is now fixed, and cleanup happens as expected.
- Loading branch information
1 parent
5b68091
commit 09578a4
Showing
4 changed files
with
193 additions
and
37 deletions.
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
This file contains 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