Re: Truncating/vacuuming relations on full tablespaces

On Fri, Jan 15, 2016 at 1:24 PM, Kevin Grittner <kgrittn(at)gmail(dot)com> wrote:
> On Fri, Jan 15, 2016 at 11:41 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Anybody else want to weigh in with thoughts on any of this?
>
> Leaving aside VACUUM issues for a moment, what problems to you see
> with an empty table that has no visibility map or free space map
> fork? In other words, for the TRUNCATE case we could either skip
> these if there is an error, or not even try to build them at all.
> Either seems better than the status quo.

The status quo *is* that we don't try to build them at all.

rhaas=# create table foo (a int, b int);
CREATE TABLE
rhaas=# insert into foo values (1,1);
INSERT 0 1
rhaas=# vacuum analyze foo;
VACUUM
rhaas=# select relfilenode from pg_class where relname = 'foo';
relfilenode
-------------
16385
(1 row)

In another window:

-rw------- 1 rhaas staff 8192 Jan 15 13:45 16385
-rw------- 1 rhaas staff 24576 Jan 15 13:45 16385_fsm
-rw------- 1 rhaas staff 8192 Jan 15 13:45 16385_vm

Back to the first window:

rhaas=# truncate foo;
TRUNCATE TABLE
rhaas=# select relfilenode from pg_class where relname = 'foo';
relfilenode
-------------
16388
(1 row)

Back to the second window:

[rhaas 16384]$ ls -l 16388*
-rw------- 1 rhaas staff 0 Jan 15 13:46 16388

There's no full disk involved here or anything. Just a plain old TRUNCATE.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company