I'm working on a dev system, and I have been restoring to a database, say "foo", that I'm using for dev purposes. As I'm working through the kinks, I've just been running DROP DATABASE foo. However, I quickly realized I ate up all the space on my disk. Crap.
Does VACUUM FULL, from a different logical database, free up space from the database that I previously dropped (foo)? I tried this from a different logical database, and free space was reclaimed, but I don't THINK it was enough to account for all of the CREATE DATABASE/DROP DATABASE calls I made. It might have just VACUUM'ed the logical database I ran from.
There must be a way to reclaim that space without doing a total database init?
So I reinitialized the database from a backup, roughly following these steps. After the restore, I've reclaimed a TON of space on disk! This works for now, but any help regarding how to cleanup a dropped database would still be useful.
So I've managed to collect some more information about this issue... Here's what I've come up with as an example:
Initial partition size: Size Used Avail Use% Mounted on 25G 8.1G 16G 35% /apps1 After creating my new database and populating it: 25G 18G 6.4G 73% /apps1 After Dropping the database using "DROP database mydb" from a separate logical DB: 25G 13G 11G 56% /apps1
So it appears to me that the new DB took up ~9.6 GB on disk. However, after dropping it, the reclaimed disk space only grew by ~4.6G. So, there's roughly 5 GB of space that makes me wonder what's going on!?
And it continues this cycle when I recreate, populate, and drop again.
Does anyone have any idea what's lingering after a "DROP DATABASE" command is issued?