patternsqlMajor
I need to run VACUUM FULL with no available disk space
Viewed 0 times
fullvacuumavailablediskneedwithspacerun
Problem
I have one table that is taking up close to 90% of hd space on our server. I have decided to drop a few columns to free up space. But I need to return the space to the OS. The problem, though, is that I'm not sure what will happen if I run VACUUM FULL and there is not enough free space to make a copy of the table.
I understand that VACUUM FULL should not be used but I figured it was the best option in this scenario.
Any ideas would be appreciated.
I'm using PostgreSQL 9.0.6
I understand that VACUUM FULL should not be used but I figured it was the best option in this scenario.
Any ideas would be appreciated.
I'm using PostgreSQL 9.0.6
Solution
Method with little to no downtime (minimal user-impact)
NOTE: I have tested this on 9.1. I have no 9.0 server lying around here. I am preeeettty sure though it will work on 9.0 though.
CAUTION (As noted in the comments by @erny):
You can do this with pretty much no down-time by using a temporary tablespace. The down-time will be in the form of exclusive locks. But only on the table you are vacuuming. So all that will happen is that client queries will simply wait for the lock to be acquired if they access the table in question. You don't need to close existing connections.
One thing to be aware of though, is that moving the table and the vacuum full will themselves need to wait for an exclusive lock first!
First, you obviously need some additional storage. As
Next, mount the new device and make it available as tablespace:
You can list the tablespaces easily using:
Double-check the current tablespace of your table (you need to know where to move it back to):
If it's
If that is
Now move the table over:
Vacuum it:
Move it back:
Remove the temporary space:
NOTE: I have tested this on 9.1. I have no 9.0 server lying around here. I am preeeettty sure though it will work on 9.0 though.
CAUTION (As noted in the comments by @erny):
Note that high CPU load due to I/O operations may be expected.You can do this with pretty much no down-time by using a temporary tablespace. The down-time will be in the form of exclusive locks. But only on the table you are vacuuming. So all that will happen is that client queries will simply wait for the lock to be acquired if they access the table in question. You don't need to close existing connections.
One thing to be aware of though, is that moving the table and the vacuum full will themselves need to wait for an exclusive lock first!
First, you obviously need some additional storage. As
Stéphane mentions in the comments, this needs to be at least twice as big as the table in question as VACUUM FULL does a full copy. If you are lucky and can dynamically add a disk to the machine, do that. In the worst case you can just attach an USB disk (risky and slow though)!Next, mount the new device and make it available as tablespace:
CREATE TABLESPACE tempspace LOCATION '/path/to/new/folder';You can list the tablespaces easily using:
\dbDouble-check the current tablespace of your table (you need to know where to move it back to):
SELECT tablespace FROM pg_tables WHERE tablename = 'mytable';If it's
NULL, it will be in the default tablespace:SHOW default_tablespace;If that is
NULL as well, it will likely be pg_default (check the official docs in case it's changed).Now move the table over:
ALTER TABLE mytable SET TABLESPACE tempspace;
COMMIT; -- if autocommit is offVacuum it:
VACUUM FULL mytable;Move it back:
-- assuming you are using the defaults, the tablespace will be "pg_default".
-- Otherwise use the value from the SELECT we did earlier.
ALTER TABLE mytable SET TABLESPACE pg_default;
COMMIT; -- if autocommit is offRemove the temporary space:
DROP TABLESPACE tempspace;Code Snippets
Note that high CPU load due to I/O operations may be expected.CREATE TABLESPACE tempspace LOCATION '/path/to/new/folder';SELECT tablespace FROM pg_tables WHERE tablename = 'mytable';SHOW default_tablespace;ALTER TABLE mytable SET TABLESPACE tempspace;
COMMIT; -- if autocommit is offContext
StackExchange Database Administrators Q#17057, answer score: 32
Revisions (0)
No revisions yet.