我有9.1数据库的本地安装,几个表有cca. 300兆的记录和数据库增长到大约20 GB.之后我从命令中删除了删除它的所有记录(我应该使用截断,但我不知道).所以我在我的数据库上做了全真空以回收磁盘空间,但它没有帮助.我的问题看起来与
this one相同,但没有提供解决方案.我已经检查过
this thread和“恢复磁盘空间”的文档,但仍然无法找到解决方案.我使用此代码来获取所有表的大小
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','information_schema')
AND C.relkind <> 'i'
AND nspname !~ '^pg_toast'
ORDER BY pg_total_relation_size(C.oid) DESC
LIMIT 15;
但总计小于1GB
SELECT pg_database.datname,pg_size_pretty(pg_database_size(pg_database.datname)) AS size FROM pg_database
仍显示约20 GB.任何建议都非常感谢.
虽然您没有说明,但我假设您对已经遵循的文档的引用已经对数据库和/或受影响的表执行了VACUUM FULL.您还没有指定您正在使用的postgresql版本 – 我将假设它是> 9.0(VACUUM FULL在此之前表现不同).
VACUUM FULL会将受影响的表重写为新文件,然后删除旧文件.但是,如果任何进程仍然打开旧文件,则操作系统实际上不会删除该文件 – 直到最后一个进程关闭它.
如果这不切实际,那么您可以验证这是否是您的问题,并找出文件打开的进程.
如果使用Linux(或大多数其他类Unix系统),您可以使用’lsof’命令获取所有进程中打开的所有文件的列表.打开但已删除的文件将在文件名后附加“(已删除)”.所以,你可以grep lsof的输出,寻找已删除的文件,如下所示：
sudo lsof -u postgres | grep 'deleted'
如果它标识仍然打开旧文件的进程,则可以使用pg_terminate_backend来终止该进程：
SELECT pg_terminate_backend(xxx);
其中xxx是进程的PID,在lsof输出中找到.
如果使用Windows,则可以应用相同的原则,因为postgres使用FILE_SHARE_DELETE标志打开文件,该标志允许它删除在另一个进程中打开的文件. ‘handle‘命令大致相当于lsof,虽然我不确定你是否可以判断文件是否被删除,因此可能需要一些额外的工作.
另一个问题是为什么任何这样的过程都会挂在旧的文件句柄上.但是你在thread中引用了你的问题,Tom Lane似乎暗示它可能发生.
