Skip to content
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

Closed
RichardJCai opened this issue Sep 1, 2021 · 2 comments · Fixed by #69789
Assignees
Labels
C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions)

Comments

@RichardJCai
Copy link
Contributor

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:

CREATE DATABASE test;
USE test;
CREATE SCHEMA s;
CREATE TYPE s.testenum AS ENUM ('foo', 'bar', 'baz');
CREATE TABLE test.s.pg_indexdef_test (
    a INT PRIMARY KEY,
    e s.testenum
);
CREATE TABLE test.s.pg_constraintdef_test (
  a int,
  FOREIGN KEY(a) REFERENCES test.s.pg_indexdef_test(a) ON DELETE CASCADE
);
DROP DATABASE test;

This results in ERROR: error resolving referenced table ID 65: descriptor is being dropped

@RichardJCai RichardJCai added C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions) T-sql-schema-deprecated Use T-sql-foundations instead labels Sep 1, 2021
@ajwerner
Copy link
Contributor

ajwerner commented Sep 1, 2021

@fqazi this looks similar to something you found recently. Can you take a look?

@fqazi fqazi self-assigned this Sep 2, 2021
@fqazi
Copy link
Collaborator

fqazi commented Sep 2, 2021

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

craig bot pushed a commit that referenced this issue Sep 10, 2021
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>
@craig craig bot closed this as completed in fd11f94 Sep 10, 2021
@healthy-pod healthy-pod removed the T-sql-schema-deprecated Use T-sql-foundations instead label May 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants