On 15 January 2016 at 15:21, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Sep 4, 2015 at 8:04 AM, Thom Brown <t...@linux.com> wrote: >> Currently, when attempting to vacuum a table on a tablespace with no space >> left, we get an error: >> >> postgres=# vacuum test; >> ERROR: could not extend file >> "pg_tblspc/19605/PG_9.6_201508111/12382/19616_vm": No space left on device >> HINT: Check free disk space. >> >> This is because it first tries to grow the visibility map file. >> >> We also get a similar problem when attempting to truncate with restart >> identity: >> >> postgres=# truncate table test restart identity; >> ERROR: canceling autovacuum task >> CONTEXT: automatic vacuum of table "postgres.public.test" >> ERROR: could not extend file "base/12382/16391": No space left on device >> HINT: Check free disk space. >> STATEMENT: truncate table test restart identity; >> >> I guess a workaround for the 2nd case is to truncate without restarting the >> identify, then truncate again with restart identify, or just resetting the >> sequence. In any case, someone will likely be running this command to free >> up space, and they can't due to lack of space. >> >> But shouldn't we not be creating FSM or VM files when truncating? > > That seems like it might possibly be a good thing to avoid, but we're > not doing it in either of those examples. So, I am confused.
So am I, reading it back I'm not sure why I said that now. The problem is with attempting to extend some file on a full tablespace during a vacuum or a truncate. I guess they are different but related problems. Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers