Skip to content

sql: dropped table remains visible in the same transaction #57494

@jayshrivastava

Description

@jayshrivastava

Describe the problem

When you alter a table subsequently drop/rename it inside a transaction, the old table is still visible via pg_catalog, show tables (which uses pg_catalog tables), and information_schema.tables.

To Reproduce
With a drop:

root@localhost:26257/defaultdb> create table foo;

root@localhost:26257/defaultdb> show tables;
  schema_name | table_name | type  | owner | estimated_row_count
--------------+------------+-------+-------+----------------------
  public      | foo        | table | root  |                   0

root@localhost:26257/defaultdb> begin;

root@localhost:26257/defaultdb  OPEN> alter table foo rename to bar;

root@localhost:26257/defaultdb  OPEN> show tables;
  schema_name | table_name | type  | owner | estimated_row_count
--------------+------------+-------+-------+----------------------
  public      | bar        | table | root  |                   0

root@localhost:26257/defaultdb  OPEN> drop table bar;

root@localhost:26257/defaultdb  OPEN> show tables;
  schema_name | table_name | type  | owner | estimated_row_count
--------------+------------+-------+-------+----------------------
  public      | bar        | table | root  |                   0

root@localhost:26257/defaultdb  OPEN> select * from bar;
ERROR: relation "bar" does not exist
SQLSTATE: 42P01

With a rename:

root@localhost:26257/defaultdb> create table foo;

root@localhost:26257/defaultdb> begin;

Time: 0ms total (execution 0ms / network 0ms)

root@localhost:26257/defaultdb  OPEN> alter table foo add column i int;

Time: 5ms total (execution 5ms / network 0ms)

root@localhost:26257/defaultdb  OPEN> show tables;
  schema_name | table_name | type  | owner | estimated_row_count
--------------+------------+-------+-------+----------------------
  public      | foo        | table | root  |                   0

root@localhost:26257/defaultdb  OPEN> alter table foo rename to bar;

root@localhost:26257/defaultdb  OPEN> show tables;
  schema_name | table_name | type  | owner | estimated_row_count
--------------+------------+-------+-------+----------------------
  public      | foo        | table | root  |                   0

root@localhost:26257/defaultdb  OPEN> select * from foo;
ERROR: relation "foo" does not exist
SQLSTATE: 42P01

With a rename using information_schema.tables:

root@localhost:26257/defaultdb> create table foo;

root@localhost:26257/defaultdb> begin;

root@localhost:26257/defaultdb  OPEN> alter table foo rename to bar;

root@localhost:26257/defaultdb  OPEN> show tables;
  schema_name | table_name | type  | owner | estimated_row_count
--------------+------------+-------+-------+----------------------
  public      | bar        | table | root  |                   0

root@localhost:26257/defaultdb  OPEN> select * from information_schema.tables where table_name = 'bar';
  table_catalog | table_schema | table_name | table_type | is_insertable_into | version
----------------+--------------+------------+------------+--------------------+----------
  defaultdb     | public       | bar        | BASE TABLE | YES                |       2

root@localhost:26257/defaultdb  OPEN> drop table bar;

root@localhost:26257/defaultdb  OPEN> select * from information_schema.tables where table_name = 'bar';
  table_catalog | table_schema | table_name | table_type | is_insertable_into | version
----------------+--------------+------------+------------+--------------------+----------
  defaultdb     | public       | bar        | BASE TABLE | YES                |       2

Expected behavior
The table should not be visible via after being dropped/renamed.

Additional Notes
This shows up in these roachtest failures:
#56081 (comment)
#56081 (comment)
#56081 (comment)
#56081 (comment)
#56081 (comment)
#56081 (comment)

Note that each alter table statement implicitly performs a select table table_name from [show tables] limit 1 when generating random SQL statements. The last alter table statement in each example should not be able to generate itself because the table does not exist. Because the table still exists via show tables, the last statement get generated using a non existing table.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-schema-changesA-schema-transactionalA-sql-pgcompatSemantic compatibility with PostgreSQLC-bugCode not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions