There's another side to this and that I am not sure it is a backend crash. Here is what I did to reproduce:
2 virtual disk images: 100mb for main data, 40 MB for WAL. work_mem set to 256MB. The idea is to test different out of space conditions. Create table as ...; drop table; select pg_size_pretty(pg_current_xlog_location() - '0/0'); I played around with parameters to determine how different kinds of out of space errors were handled. 1. running out of temp space was cleaned up without a server restart needed. 2. A relation running out of disk space *seemed* to get cleaned up. 3. Running out of WAL space left *both* temp and non-temp files. I wonder about a different solution. Would it be possible to special case vacuum to check for and remove (or just move to where they can be removed) files when vacuuming pg_class? At the point we are vacuuming pg_class, we ought to be able to know that a relfilenode shouldn't be used anymore, right? -- Best Regards, Chris Travers Database Administrator Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com Saarbrücker Straße 37a, 10405 Berlin
