Truncating/vacuuming relations on full tablespaces - Mailing list pgsql-hackers

From Thom Brown
Subject Truncating/vacuuming relations on full tablespaces
Date
Msg-id CAA-aLv4T2fY8Uogy0y0B0U7Y+eywEue=M6PPjMKQgO+MjF9uSw@mail.gmail.com
Whole thread Raw
Responses Re: Truncating/vacuuming relations on full tablespaces  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Re: Truncating/vacuuming relations on full tablespaces  (Robert Haas <robertmhaas@gmail.com>)
List 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

pgsql-hackers by date:

Previous
From: Anastasia Lubennikova
Date:
Subject: Re: PATCH: index-only scans with partial indexes
Next
From: Teodor Sigaev
Date:
Subject: Re: [PATCH] Microvacuum for gist.