On Thu, Apr 7, 2016 at 2:15 AM, Jim Nasby <jim.na...@bluetreble.com> wrote:
> 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.
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