This is too late for 9.6 at this point and certainly requires discussion anyway, so please add it to the next CommitFest.
If the goal here is to free up space via truncation when there's a real emergency, perhaps there's some other steps that should be taken as well. What immediately comes to mind is scanning the heap backwards and stopping on the first page we can't truncate.
There might be some other non-critical things we could skip in emergency mode, with an eye towards making it as fast as possible.
BTW, if someone really wanted to put some effort into this, it would be possible to better handle filling up a single filesystem that has both data and WAL by slowly shrinking the VM/FSM to make room in the WAL for vacuum records. ISTM that's a much more common problem people run into than filling up a separate tablespace.
Thank you Jim. I will look into it and share my findings about it.
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com
