debugsqlMinor
VACUUM FULL fails with 'ERROR: Check free disk space'
Viewed 0 times
fullerrorvacuumfailsfreewithdiskspacecheck
Problem
I am using Postgres 9.4. I have a database that
I have 320GB of SSD on the server of which 89GB is available:
I can't easily add more disk space to the server. Is there anything else I can do?
I found this question, so I can try that if needed. But I was wondering if I could tell VACUUM FULL to work with less memory.
\l+ tells me is 164 GB. When I try to run VACUUM FULL on the database, I get this error (after many hours): ERROR: could not extend file "base/18222/20547.2": wrote only 4096
of 8192 bytes at block 279347
HINT: Check free disk space.I have 320GB of SSD on the server of which 89GB is available:
$ df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 315G 211G 89G 71% /
udev 10M 0 10M 0% /dev
tmpfs 6.4G 192K 6.4G 1% /run
/dev/disk/by-label/DOROOT 315G 211G 89G 71% /
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 13G 4.0K 13G 1% /run/shmI can't easily add more disk space to the server. Is there anything else I can do?
I found this question, so I can try that if needed. But I was wondering if I could tell VACUUM FULL to work with less memory.
Solution
According to postgresql documentation:
VACUUM FULL actively compacts tables by writing a complete new
version of the table file with no dead space. This minimizes the size
of the table, but can take a long time. It also requires extra disk
space for the new copy of the table, until the operation completes.
So if you have one big table vacuum full can easily eat all your disk space. Maybe the best thing would be to do a full backup/restore - the result will be the same as if you did a vacuum full.
VACUUM FULL actively compacts tables by writing a complete new
version of the table file with no dead space. This minimizes the size
of the table, but can take a long time. It also requires extra disk
space for the new copy of the table, until the operation completes.
So if you have one big table vacuum full can easily eat all your disk space. Maybe the best thing would be to do a full backup/restore - the result will be the same as if you did a vacuum full.
Context
StackExchange Database Administrators Q#96545, answer score: 4
Revisions (0)
No revisions yet.