简短回答：从备份还原。然后检查您的设置，您正在运行一个不安全的系统。
长回答：
假设你没有备份，但你需要数据库，你已经学到了宝贵的一课。采取和检查您的备份。
如果是一个简单的SELECT * FROM bad_table失败了，那么就是表有问题，如果不是，COPY立即输出数据，你很幸运，只是一个索引被破坏了。
那就把你剩下的table都扔了。
然后执行一些检查以确保数据在恢复并将其放回生产之前处于正常状态。
现在--除了PostgreSQL中的bug（不太可能），这应该是不可能的。因为我们正在谈论一个丢失的文件，我猜你的磁盘报告数据是flushed and synced，而实际上不是。无论如何，检查你的postgresql.conf中的fsync设置。

在我的本地服务器上，这是我的一个测试数据库的问题，只是删除这个数据库。现在没事了。对于生产服务器来说，删除数据库不是一个好主意。

我在Postgres 12上运行真空时遇到了同样的问题。

此数据库是生产数据库，但幸运的是，它不是面向客户的。它跟踪3个重要的大型Isilon群集的存储详细信息，我需要恢复它。这就是修复我的系统的方法。
看到错误后：

database is not accepting commands to avoid wraparound data loss in database ((database_2_name)) 

HINT: Stop the postmaster and vacuum that database in single-user mode. You might also need to commit or roll back prepared transactions, or drop stale replication slots.

我停止了邮局主管（CentOS7 + Systemd）

systemctl stop postgresql-12.service

然后在单用户模式下启动postgres：

# su - postgres
postgres --single -D /var/cache/insightiq/pgsql/data  ((database_1_name))

数据库会弹出一个小警告：

> WARNING:  database with OID 16403 must be vacuumed within 990276 transactions
> HINT:  To avoid a database shutdown, execute a database-wide VACUUM in that database.
         You might also need to commit or roll back old prepared transactions, or drop stale replication slots.

PostgreSQL stand-alone backend 12.4
backend>

然后尝试吸尘，但在我的数据库的OID（16403）下发现缺少 number？。我注意到此16403与为我的（（database_1_name））设置的存储的顶级相关联

backend> vacuum

<2023-01-05 19:00:41.150 UTC [4229] > ERROR:  could not open file "base/16403/2613": No such file or directory
<2023-01-05 19:00:41.150 UTC [4229] > STATEMENT:  vacuum

正如最初的发帖者所建议的，我确实尝试在位置（数据应该在的位置）添加一个文件，但当我再次尝试真空时，错误没有变化。同样的“无法打开文件“base/16403/2613””
在我的例子中，我的大型数据库结构在NFS上关闭了，当我运行vacuum时，我可以看到它们发生了变化。我搜索了我的本地文件系统中名为'base/16403'的内容，并在/var/cache/insightiq/pgsql/data/base/16403中找到了一个数据不应该存在的目录结构。
别无选择，我决定**GABLE！**我在vacuum抱怨的位置（缓存位置而不是数据位置）创建了一个空文件

# ls /var/cache/insightiq/pgsql/data/base/16403/2613
ls: cannot access /var/cache/insightiq/pgsql/data/base/16403/2613: No such file or directory
# touch /var/cache/insightiq/pgsql/data/base/16403/2613
# chown postgres:postgres /var/cache/insightiq/pgsql/data/base/16403/2613

Presto.单用户vacuum在我的数据库上工作。vacuum建议在其他数据库上也这样做，这很顺利。最后，我停止/启动了所有的东西，这个系统又工作了。