From: | Thom Brown <thom(at)linux(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Truncating/vacuuming relations on full tablespaces |
Date: | 2015-09-04 12:04:53 |
Message-ID: | CAA-aLv4T2fY8Uogy0y0B0U7Y+eywEue=M6PPjMKQgO+MjF9uSw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
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?
ISTM that the vacuum case is one we'd really want to avoid, though, as it's
trickier to work around the problem.
Thom
From | Date | Subject | |
---|---|---|---|
Next Message | Teodor Sigaev | 2015-09-04 12:11:12 | Re: [PATCH] Microvacuum for gist. |
Previous Message | Anastasia Lubennikova | 2015-09-04 11:28:29 | Re: PATCH: index-only scans with partial indexes |