postgreSQL vacuum temp files?

Question

I've got a "little" problem. A week ago my database was reaching full disk capasity. I deleted many rows in different tables trying to free up disk space. After wich i tried running a full vacuum wich did not complete.

What i want to know is. When i stopped the vacuum from fully compliting does it leave any temp files on the disk that i have to delete manualy? I now have a database wich is at a 100% disk capasity, wich needlessly to say is a big problem.

Any tips to free disk space?

I'm running SUSE with a postgres 8.1.4 database.

Answer 1

First of all:

UPGRADE

Even if you can't to 8.2, 8.3 or 8.4 - at least upgrade to newest 8.1 (which is 8.1.17 at the moment, but will be 8.1.18 in 1-2 days).

Second: diagnose what is the problem.

Use du tool to diagnose where exactly did the space go. What directory is occupying too much space?

Check with df what is total used space, and then check how much of it is PostgreSQL directory.

The best option is to:

cd YOUR_PGDATA_DIR
du -sk *
cd base
du -sk *
cd LARGEST DIR FROM PREVIOUS COMMAND
du -sk * | sort -nr | head

Now, that you know which directory in PGDATA is using space you can do something about it.

if it's logs or pg_temp - restart pg or remove logs (pg_clog and pg_xlog are not logs in common meaning of the word, never delete anything from there!).

If it's something in your base directory, then:

numerical directories in base directory relate to databases. You can check it with:

select oid, datname from pg_database;

When you know the database that is using most of the space, connect to it, and check which files are using most of the space.

File names will be numerical with optional ".digits" suffix - this suffix is (for now) irrelevant, and you can check what exactly the file represents by issuing:

select relname from pg_class  where relfilenode = <NUMBER_FROM_FILE_NAME>;

Once you know which tables/indexes use most of the space - you can VACUUM FULL it, or (much better) issue CLUSTER command on them.

Answer 2

On the new tangent to your problem, you can find out what in the database is using lots of space using a query. That can help you locate candidates to TRUNCATE to reclaim enough working space to clean up the ones with deleted info.

Note that deleting lots of rows but not VACUUMing frequently enough to keep disk space in check will often lead to a condition called index bloat, which VACUUM FULL doesn't help with at all. You'll know you're there when the query I suggested shows most of your space is taken up by indexes rather than regular tables. You'll need CLUSTER, which needs as much free disk space as the table itself to rebuild everything, to recover from that problem.