PostgreSQL：TRUNCATE后未释放磁盘空间

我有TRUNCATE一个巨大的表（〜120Gb），名为files：

TRUNCATE files;
VACUUM FULL files;

表大小为0，但没有释放磁盘空间。有什么想法如何找回丢失的磁盘空间吗？

更新： 大约12个小时后释放了磁盘空间，我这边没有采取任何措施。我使用Ubuntu 8.04服务器。

postgresql truncate disk-space

— 亚当·马坦（Adam Matan）
source

我本来建议“给它真空！”，但考虑到您刚刚做了，我建议将其移交给pg-hackers或pg-performance列表（并链接回到线程或在获得答案后再回答）一）。

— Denis de Bernardy 2011年

这个链接（postgresql.1045698.n5.nabble.com/…）是否为您提供任何建议？也许还有一些东西可以访问桌子或类似的东西。

— DrColossos 2011年

@DrColossos：我在源代码中读到一条评论（一条评论，我现在找不到），它说PostgreSQL通知所有连接即将进行截断，并锁定了必要的资源。（有几个表，包括表本身，索引，序列和Toast表。）我敢肯定，我是通过ExecuteTruncate（）进行跟踪来找到注释的，但是我对此并不是100％肯定的。

— Mike Sherrill'Cat Recall'

根据源代码中的注释，truncate创建一个新的空存储文件，并在提交时删除旧的存储文件。（文档建议就操作系统而言，“存储文件”只是一个文件，但我可能会误解该术语。）

为该关系创建一个新的空存储文件，并将其分配为relfilenode值。旧的存储文件计划在提交时删除。

由于它似乎正在删除文件，因此我可以想象某些情况下底层操作系统可能不会立即释放该空间。我想在某些情况下，例如，存储文件可能最终会放在Windows下的回收站中。但就我而言，在PostgreSQL 9下截断一个表会立即增加Windows下的可用空间。

截断也会记录在WAL日志中。我不知道这可能有多少影响。

— 迈克·谢里尔（Mike Sherrill）
source

可以想象，另一个后端进程仍然具有打开文件的文件描述符。如果再次发生这种情况，我将尝试终止所有其他后端进程，以查看是否有所作为。

— Peter Eisentraut 2011年

我很确定我读过ExecuteTruncate（）应该确保不会发生这种情况。锁定最终删除旧存储文件所需的资源的所有部分。但是我不知道我在源代码中找到了什么。我只是在线浏览；这样很容易迷路。

— Mike Sherrill'Cat Recall'