PostgreSQL数据库异常膨胀至3.5TB，无法定位对应OID表求助

你的PostgreSQL数据库出现了严重的异常膨胀，从正常300GB涨到3.5TB，而且/base/45075466下堆了3000个1GB的文件，查遍对象和Schema都找不到异常点，用OID 21037129也查不到对应表——我来帮你一步步排查可能的原因和解决办法：

1. 先排查事务ID冻结/回绕问题 #

PostgreSQL为了防止事务ID回绕，会自动冻结旧数据，但如果这个过程卡住或失效，可能会导致表空间被大量冻结相关的临时数据占满。你可以先执行这条SQL检查：

SELECT datname, age(datfrozenxid) FROM pg_database;

如果目标数据库的age(datfrozenxid)值接近2^31-1（约21亿），说明冻结操作没正常跑起来，需要手动触发：

-- 针对整个数据库执行冻结，加VERBOSE可以看进度
VACUUM FREEZE VERBOSE your_database_name;

2. 检查未清理的临时表/临时文件 #

很多时候应用创建的临时表如果遇到会话异常中断，或者没被自动清理，会在表空间留下大量残留文件。你可以先查当前活跃的临时表：

SELECT relname, relnamespace FROM pg_class WHERE relkind = 't';

也可以翻PostgreSQL的日志，搜有没有临时表相关的报错。如果确定是临时文件残留，重启PostgreSQL服务（注意选业务低峰期），重启后临时文件会被自动清理。

3. 深挖隐藏对象或失效OID #

你提到用OID 21037129查不到表，可能是对象已经被删除，但文件因为事务未提交、清理机制延迟等原因没被删掉。试试这几个方法：

• 用oid2name工具（在PostgreSQL的bin目录下）直接查OID对应的对象：

oid2name -d your_database_name -o 21037129

• 安装pgstattuple扩展，扫描所有对象的真实占用情况：

CREATE EXTENSION IF NOT EXISTS pgstattuple;
-- 按占用大小排序所有对象，包括系统表
SELECT relname, relkind, pg_size_pretty(pg_total_relation_size(oid)) AS total_size
FROM pg_class
ORDER BY pg_total_relation_size(oid) DESC;

• 检查表的死元组情况，死元组过多也会导致膨胀：

SELECT relname, n_dead_tup, n_live_tup, pg_size_pretty(pg_total_relation_size(oid))
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC;

4. 尝试用VACUUM FULL清理无效文件 #

如果上面的排查都没找到根源，可以试试VACUUM FULL（注意：这个操作会锁表，一定要在业务低峰期执行），它会重建表并彻底清理所有无效的磁盘文件：

VACUUM FULL VERBOSE;

最后提醒：操作前一定要先备份数据库，避免意外数据丢失。

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