On 4/6/16 11:06 AM, Robert Haas wrote:
> 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.
--
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
