Question

我在ubuntu 12.0.4上的postgresql中运行此查询：

SELECT t2.p AS prop, t2.o AS obj, COUNT(t2.o) AS num 
FROM "class_Event" AS t1, 
  ((SELECT s,p,o FROM "prop_sliceHasAnomaly")  
   UNION (SELECT s,p,o FROM "prop_eventHasDuration")  
   UNION (SELECT s,p,o FROM "prop_sliceHasEndEvent")  
   UNION (SELECT s,p,o FROM "prop_eventPrecedeInCPU")  
   UNION (SELECT s,p,o FROM "prop_eventFollowInTask")  
   UNION (SELECT s,p,o FROM "prop_topObjectProperty")  
   UNION (SELECT s,p,o FROM "prop_eventDetails")  
   UNION (SELECT s,p,o FROM "prop_switchTo")  
   UNION (SELECT s,p,o FROM "prop_eventIsExecutedOn")  
   UNION (SELECT s,p,o FROM "prop_runningAction")  
   UNION (SELECT s,p,o FROM "prop_anomalyHasSlice")  
   UNION (SELECT s,p,o FROM "prop_eventPrecedeInTrace")  
   UNION (SELECT s,p,o FROM "prop_sliceHasStartEvent")  
   UNION (SELECT s,p,o FROM "prop_eventHasActiveDuration")  
   UNION (SELECT s,p,o FROM "prop_eventFollowInTrace")  
   UNION (SELECT s,p,o FROM "prop_runningTask")  
   UNION (SELECT s,p,o FROM "prop_eventOrdering")  
   UNION (SELECT s,p,o FROM "prop_domain")  
   UNION (SELECT s,p,o FROM "prop_sliceHasFunctionality")  
   UNION (SELECT s,p,o FROM "prop_traceContainsEvent")  
   UNION (SELECT s,p,o FROM "prop_eventHasDurationFromPreviousOccurrence")  
   UNION (SELECT s,p,o FROM "prop_eventPrecedeOccurrence")  
   UNION (SELECT s,p,o FROM "prop_eventPrecedeinTask")  
   UNION (SELECT s,p,o FROM "prop_switchFrom")  
   UNION (SELECT s,p,o FROM "prop_eventEndAt")  
   UNION (SELECT s,p,o FROM "prop_subPropertyOf")  
   UNION (SELECT s,p,o FROM "prop_eventFollowOccurrence")  
   UNION (SELECT s,p,o FROM "prop_eventFollowInCPU")  
   UNION (SELECT s,p,o FROM "prop_subClassOf")  
   UNION (SELECT s,p,o FROM "prop_eventHasDurationToNextOccurrence")  
   UNION (SELECT s,p,o FROM "prop_requestComponent")  
   UNION (SELECT s,p,o FROM "prop_eventStartAt")  
   UNION (SELECT s,p,o FROM "prop_range")  
   UNION (SELECT s,p,o FROM "prop_functionalityHasSlice") ) AS t2 
WHERE t1.s = t2.s 
GROUP BY t2.p, t2.o 
HAVING (COUNT(t2.o) > 1)

但是我从posgresql发出了这个错误：

ERROR:  could not write block 713 of temporary file: Aucun espace disponible sur le périphérique
HINT:  Perhaps out of disk space?

********** Erreur **********

ERROR: could not write block 713 of temporary file: Aucun espace disponible sur le périphérique
État SQL :53100
Astuce : Perhaps out of disk space?

我已经使用命令df -h

检查了足够的磁盘空间

df -h
df: «/var/lib/lightdm/.gvfs»: Permission non accordée
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/sda5           37G     35G   46M 100% /
udev                16G    4,0K   16G   1% /dev
tmpfs              6,3G    984K  6,3G   1% /run
none               5,0M       0  5,0M   0% /run/lock
none                16G    216K   16G   1% /run/shm
/dev/sda6           37G    411M   35G   2% /opt
/dev/sda9          499G    435G   40G  92% /home
/dev/sda7           37G    4,7G   30G  14% /usr
/dev/sda8           37G    5,1G   30G  15% /usr/local

似乎/home上有 40GB 可用空间磁盘。所以我想知道是什么让这个错误引起的？是否有可以在postgresql配置中设置的磁盘空间限制参数？

有人对此有所了解吗？

Answer 1

它正在写一个临时文件。他们已写入temp_tablespaces，其中包含以下内容：

默认值为空字符串，这会导致在当前数据库的默认表空间中创建所有临时对象。

意味着它会将临时文件写入data_directory。要查看它的位置，请运行SHOW data_directory。我希望您能获得/var/lib/pgsql/9.3/data/之类的结果，表明PostgreSQL的数据位于/var。

（确保检查一下;如果你的临时表空间是tempfs，那么它基本上是一个ramdisk，你应该把它移到其他地方，因为它对性能有害并且是一个问题对于大型临时文件。）

在您的系统上，/var是/文件系统的一部分，它已满。因此包含PostgreSQL数据的分区已满，PostgreSQL正确地将此报告为错误。

释放空间的选项包括：

确保/tmp中的旧临时文件被删除
从/var/log
删除旧的PostgreSQL日志。根据操作系统/发行版，它们的位置有些变化，你没有提到;他们通常会在/var/log/postgresql/或/var/lib/pgsql/9.3/data/pg_log。重要：不删除PostgreSQL数据目录中的任何其他内容;特别是，pg_xlog和pg_clog是数据库系统的重要组成部分，不得以任何方式删除，移动或更改。
在PostgreSQL中删除或TRUNCATE表（永久销毁数据）
DROP ping PostgreSQL中不需要的索引
卸载程序
...

但最好的选择是：

获取更大的磁盘。

为什么postgresql会在磁盘空间足够的情况下提示“磁盘空间不足”？

1 个答案: