Truncating/vacuuming relations on full tablespaces

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

Responses

Browse pgsql-hackers by date

  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