Re: Truncating/vacuuming relations on full tablespaces

On Fri, Jan 15, 2016 at 1:24 PM, Kevin Grittner <kgrittn@gmail.com> wrote:
> On Fri, Jan 15, 2016 at 11:41 AM, Robert Haas <robertmhaas@gmail.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