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 >
