可能无法释放 TEMPORARY 表占用的磁盘空间的所有原因/可能性是什么？

Question

我们使用的是 PostgreSQL v8.2.3。我们是一个基于 web 的应用程序，我们使用 pgpool-II v 2.0.1 纯粹是为了连接池（我们不使用 pgpool 的其他功能，如复制、负载平衡等）。

最近，在我们的生产服务器中，数据库磁盘空间出现了意外的急剧增长。在短短 2 天内，数据库大小从 6 GB 增长到 14 GB。

然后我运行以下查询来查找数据库中前 20 个最大关系的大小：

SELECT nspname || '.' || relname AS "relation",
pg_size_pretty(pg_total_relation_size(C.oid)) AS "total_size" FROM pg_class
C LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace) WHERE nspname NOT IN
('pg_catalog') ORDER BY pg_total_relation_size(C.oid) DESC LIMIT 20;

我在这里没有发现任何问题。甚至我可以说上述命令的“total_size”之和小于数据库本身占用的大小。我正在使用以下命令来查找数据库的大小：

select oid, datname, pg_database_size(datname) as actualsize,
pg_size_pretty(pg_database_size(datname)) as size from pg_database order by
datname;

我也曾经使用以下命令物理检查占用的数据库大小：

du -sh /usr/local/pgsql/data/base/2663326

然后我从位置“ /usr/local/pgsql/data/base/2663326 ”开始按降序物理列出文件大小。这里，“2663326”是我的数据库的 OID。

[root@dbserver 2663326]# ll -lhS |head -15
total 14G
-rw-------  1 postgres postgres  1.0G Sep  6 15:03 1508904
-rw-------  1 postgres postgres  1.0G Sep  2 21:16 1924478.10
-rw-------  1 postgres postgres  1.0G Sep  2 21:17 1924478.2
-rw-------  1 postgres postgres  1.0G Sep  2 21:19 1924478.3
-rw-------  1 postgres postgres  1.0G Sep  2 21:17 1924478.4
-rw-------  1 postgres postgres  1.0G Sep  2 21:18 1924478.5
-rw-------  1 postgres postgres  1.0G Sep  2 21:20 1924478.6
-rw-------  1 postgres postgres  1.0G Sep  2 21:20 1924478.7
-rw-------  1 postgres postgres  1.0G Sep  2 21:14 1924478.8
-rw-------  1 postgres postgres  1.0G Sep  2 21:19 1924478.9
-rw-------  1 postgres postgres  876M Sep  6 15:02 1508614
-rw-------  1 postgres postgres  615M Sep  6 15:03 1508904.1
-rw-------  1 postgres postgres  531M Sep  2 21:20 1924478.11
-rw-------  1 postgres postgres  235M Sep  6 15:02 1510463

尽管这些文件不是人类可读的，但从我能够从文件中读取的任何内容来看，我发现创建的前 10 个文件与特定的复杂应用程序报告相关。在这个复杂的报告中，我们使用 来创建临时表CREATE TEMP TABLE MY_TEMP_TABLE(col1, col2, ...)，这个临时表中的 5 列被索引并且它被大量使用。虽然临时表会在会话结束时自动删除，但我发现这些临时表占用的磁盘空间没有被释放。您还可以看到，一些文件名用小数位 ( 1924478.2, 1924478.3, etc.)编号，最大文件大小为 1 GB。特别是，这些类型的文件与这个使用临时表的复杂报告有关。

我还可以确认我的临时表没有从以下查询中列出（这表明根据系统目录表，它已被删除）：

select pn.nspname, pc.relname, pc.relfilenode from pg_class pc, pg_namespace
pn where pc.relnamespace = pn.oid and pc.relname ilike 'my_temp_table';

注意：自动真空守护程序已在服务器中运行。即使是手动 VACUUM FULL ANALYZE，后跟REINDEX命令也无法回收丢失的磁盘空间。只有当我们导出和导入时，数据库大小才恢复到原来的 6 GB 大小。

因此，根据我的观察，似乎在某个时间点/上下文中，由于某些未知原因，PostgreSQL 服务器没有正确释放临时表占用的磁盘空间。

它可能无法释放 TEMPORARY 表占用的磁盘空间的所有原因/可能性是什么？在这种情况下如何修复/处理？

Answer 1

在 Postgres 的最新版本中（我认为是从 8.3 开始），您可以为临时表分配一个特殊的表空间，这可能会对您有所帮助。此处记录了这一点：

http://www.postgresql.org/docs/9.0/static/runtime-config-client.html#GUC-TEMP-TABLESPACES

鉴于 8.2 将在今年年底取消支持，升级可能是个好主意。自 8.2 以来，VACUUM 和临时文件的处理已有许多增强功能，因此您可能会从中受益。

编辑：
我认为这个（单独的表空间）可以帮助您的原因是您可以简单地删除并重新创建表空间（文件）来回收占用的空间。

但后来我假设，由于过去 5 年中实施的所有改进，当前版本可能会释放空间，而无需您采取任何进一步的操作（特别是因为 VACUUM FULL 已在 9.0 中完全重写）