On Wed, Apr 6, 2016 at 5:15 PM, 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.
I think this comes down to what you think the remit of a VACUUM (EMERGENCY) option ought to be. I think it ought to do just enough to make VACUUM succeed instead of failing, but you could argue it ought to focus more specifically on freeing up space and skip everything else it might normally do. > 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. Really? The VM and FSM are extremely tiny; that doesn't seem likely to work out. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
