使用PostgreSQL 9.3。 我有一个长期运行的查询更新大约8M行。 有些东西显然出了问题。 2天后，我得到了一个低磁盘空间警报。 我停止了查询，这就是我所看到的。
root@server:/var/lib/postgresql/9.3/main# du -BM * | sort -n 1M global 1M pg_notify 1M pg_serial 1M pg_snapshots 1M pg_stat 1M pg_stat_tmp 1M pg_tblspc 1M pg_twophase 1M PG_VERSION 1M pg_xlog/archive_status 1M mydb.opts 1M mydb.pid 3M pg_subtrans 7M base/1 7M base/12030 7M base/12035 11M base/22029472 21M pg_clog 72M pg_multixact/offsets 315M pg_log 444M pg_multixact/members 516M pg_multixact 625M pg_xlog 3493M base/pgsql_tmp 61851M base/22053373 65372M base 注意这个： 61851M base/22053373
由于我的实际数据存储在不同的表空间中，所以我认为这是一些临时性的事务堆积。
有一些关于类似问题的在线文章，但没有find规范的解决scheme。 一般来说，build议是“运行真空满”，有时累积的残余物会消失。 这就是我现在正在做的事情，但是现在是时候了，恐怕我可能会填满剩下的磁盘空间（3GB），并把所有的东西都弄坏了。
任何人都有这方面的经验？ 这里存储了什么？ 有没有一个安全的方式来快速释放这个空间？ 或者至less把它移到其他地方（我的表空间磁盘上有足够的空间）。
我想到了。 这是我的错误。 这是一个同事在默认表空间中创build的新数据库，而不是我们自定义的表空间中的一个。
对于那些遇到类似问题的人，这里有一些我在调查中学到的东西。 base/22053373在我的情况是一个数据库的oid。 你可以看到哪个数据库是这样的：
SELECT oid, * FROM pg_database
里面的每个文件以pgtypes的oid（表或其他）命名。 最大的文件可能来自您最大的表格。 连接到数据库，并从pg_class集合中select，以找出哪个。
现在我正在将db移动到一个自定义的表空间使用
ALTER DATABASE mydb SET TABLESPACE mytablespace;
我很确定这将解决我的问题。