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

DDL statement on one table prevents stmt on another unrelated table in same transaction #38768

Closed
mguillemot-tel opened this issue Jul 9, 2019 · 1 comment
Assignees
Labels
C-investigation Further steps needed to qualify. C-label will change.

Comments

@mguillemot-tel
Copy link

Describe the problem

Inside a single transaction, DDL statements about one table prevent modifications on another totally unrelated table.

This is a regression that happened somewhere between 2.1.4 (which worked) and 19.1.2 (which exhibits the bug).

To Reproduce

Put the following in a repro.sql file:

BEGIN;

CREATE TABLE a ();

CREATE TABLE b (
    key INT
);
CREATE INDEX b_idx ON b (key);

COMMIT;

--------------------------------------------

BEGIN;

DROP TABLE a;
DROP INDEX b_idx CASCADE;

COMMIT;

Then execute it on Cockroach 19.1.2:

cockroach sql --insecure -e "drop database test; create database test;" && cockroach sql --insecure -d test < repro.sql

This will fail with the following message: pq: relation "test.public.a" does not exist

The error is raised when executing the DROP INDEX statement in the second transaction. But tables a and b have no relation whatsoever so an operation on a shouldn't prevent an operation on b.

The error message is also very confusing: the mention of b makes it seem that the error happens during the DROP TABLE statement, but it is actually about the DROP INDEX statement.

Currently it is necessary to split the second transaction into 2 different transactions for it to execute properly.

If executed on a Cockroach 2.1.4 server, the execution suceeds.

Environment:

  • CockroachDB version 19.1.2
  • Server OS: macOS 10.14.5
  • Client app: cockroach sql
@jordanlewis jordanlewis added the C-investigation Further steps needed to qualify. C-label will change. label Jul 10, 2019
@pbardea pbardea self-assigned this Sep 5, 2019
craig bot pushed a commit that referenced this issue Sep 5, 2019
40485: sql: Fix a bug with ordinal_position in information_schema.columns r=arulajmani a=arulajmani

When a column other than the last is dropped, ordinal_position in
information_schema.columns virtual table no longer matches attnum from
the pg_attribute table. This PR fixes this issue.

Fixes #39787

Release note (bug fix): ordinal_position in information_schema.columns
matches pg_attribute.attnum after a column is dropped.

40511: exec: fix explain(vec) for queries with subqueries r=jordanlewis a=jordanlewis

Also add logic tests that show the explain(vec) plans for all of the
tpch queries.

Closes #40484.

Release note: None

40516: sql: fix table lookup for drop index  r=pbardea a=pbardea

Previously, when searching for the table relevant to a particular index
when dropping the index, we would fetch all object names and require that
all those tables exist. However, if a table was deleted in the same
transaction that table name would not be resolvable and we would error.
We already had a check to see if the table being looked up was nil, but
this check would not be used because the `required` flag was set to true.

This PR just sets the flag to false, and looks at moves on to the next
table if one of them no longer is resolvable.

Addresses #38768.

Release note (bug fix): Fix faulty error when trying to delete a table
and an unrelated index in the same transaction.

Co-authored-by: Arul Ajmani <arula@cockroachlabs.com>
Co-authored-by: Jordan Lewis <jordanthelewis@gmail.com>
Co-authored-by: Paul Bardea <pbardea@gmail.com>
@pbardea
Copy link
Contributor

pbardea commented Sep 10, 2019

Closed by #40516

@pbardea pbardea closed this as completed Sep 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-investigation Further steps needed to qualify. C-label will change.
Projects
None yet
Development

No branches or pull requests

3 participants