这种幽灵表的问题我之前排查过好几次，你遇到的情况是information_schema.tables显示存在某个BASE TABLE，但实际执行drop table却提示表不存在，咱们一步步来解决：

第一步：确认表的真实状态（绕过information_schema） #

information_schema是基于系统视图封装的，有时候会因为缓存或元数据不一致出现偏差，咱们直接查底层的pg_catalog系统表来确认：

select relname, relkind, relnamespace
from pg_catalog.pg_class
where relname = 'phantom_table'
  and relnamespace = (select oid from pg_catalog.pg_namespace where nspname = 'public');

• 如果这个查询没有返回结果：说明information_schema的视图数据过时了，直接跳到第三步处理。
• 如果返回了结果：说明表的元数据确实存在，但处于异常状态，继续第二步。

第二步：排查锁与未完成事务 #

如果pg_catalog里能查到表，那大概率是有未提交的事务或者锁阻止了删除操作：

• 先查询该表的锁信息：

select locktype, pid, mode, granted
from pg_catalog.pg_locks
where relation = (select oid from pg_catalog.pg_class where relname = 'phantom_table' and relnamespace = (select oid from pg_catalog.pg_namespace where nspname = 'public'));

• 如果查到有未释放的锁，找到对应的pid，终止该进程：

select pg_terminate_backend(你的pid值);

• 之后再尝试执行drop table phantom_table cascade;，应该就能成功了。

第三步：刷新系统视图缓存与统计信息 #

如果pg_catalog里查不到表，说明是information_schema的视图数据没有更新：

• 先手动分析information_schema.tables视图，强制刷新统计信息：

analyze information_schema.tables;

• 如果还是显示幽灵表，尝试重新连接数据库（你已经试过这步，那就直接下一步），或者重启PostgreSQL服务（如果业务允许的话）——重启会清空所有系统缓存，彻底刷新元数据。

最后手段：重建数据库（仅当以上方法都失效时） #

如果所有操作都无法解决，可能是系统目录出现了轻微损坏，这时候最稳妥的办法是：

• 使用pg_dump导出整个数据库的所有数据和对象：

pg_dump -U 你的用户名 -d 你的数据库名 > db_backup.sql

• 创建一个新的空数据库：

create database 新数据库名;

• 将备份文件导入新数据库：

psql -U 你的用户名 -d 新数据库名 < db_backup.sql

• 切换到新数据库后，再查询information_schema.tables，幽灵表应该就消失了。

内容的提问来源于stack exchange，提问作者John Chrysostom