-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
sql: combination of user defined schemas, enum and foreign key causes database to not be droppable #69713
Comments
@fqazi this looks similar to something you found recently. Can you take a look? |
This was an ordering bug inside drop database cascade, we drop the schema first followed by collected objects under the schema next. As a result, when we are dropping tables, we may need to look up type descriptors, which will need access to the schema again which will be dropped. The fix here is simple we should drop the schema after any collected objects |
69486: sql: support for temporary table clean up for tenants r=fqazi a=fqazi Fixes: #67401 Previously, the temporary table clean-up did not execute for tenants. This was inadequate that temporary tables would last longer than the life span of user sessions. To address this, this patch adds support for cleaning up on a single tenant pod. Specifically removing checks for meta1 lease when under a tenant, and support for listing sessions. Release justification: low risk and fixes a tenant-related bug Release note (bug fix): Temporary tables were not properly cleaned up for tenants. 69789: sql: drop database cascade can fail resolving schemas r=fqazi a=fqazi Fixes: #69713 Previously, drop database cascade would drop the schema first, and then drop any objects under those schemas after. This was inadequate because as we look up any objects under the schemas, we may need to resolve types, which will may lead to a look up on the schema. If the schema is dropped then we will fail while resolving any types. To address this, this patch drops the objects under the schema first followed by the database. Release justification: Low risk bug fix for drop database cascade Release note (bug fix): Drop database cascade can fail while resolving a schema in a certain scenarios with the following error: "ERROR: error resolving referenced table ID <ID>: descriptor is being dropped" 69975: sql: fix interaction between stmt bundles and tracing r=yuzefovich a=yuzefovich Previously, we wouldn't generate the bundle if the verbose tracing was already enabled on the cluster because we wouldn't call `instrumentationHelper.Finish` where we actually generate the bundle. This would result in empty responses for `EXPLAIN ANALYZE (DEBUG)` as well as the requests for stmt diagnostics being stuck in "waiting" state. Fixes: #69398. Release note (bug fix): Previously, if the tracing (`sql.trace.txn.enable_threshold` cluster setting) was enabled on the cluster, the statement diagnostics collection (`EXPLAIN ANALYZE (DEBUG)`) wouldn't work. This is now fixed. Release justification: low-risk fix to a long-standing bug. Co-authored-by: Faizan Qazi <faizan@cockroachlabs.com> Co-authored-by: Yahor Yuzefovich <yahor@cockroachlabs.com>
Trying to drop a database that includes a table in a user defined schema referenced in a foreign key causes the following error:
dropping test database failed: pq: error resolving referenced table ID %d: descriptor is being dropped
Reproduction:
This results in
ERROR: error resolving referenced table ID 65: descriptor is being dropped
The text was updated successfully, but these errors were encountered: