Re: BUG #15582: ALTER TABLE/INDEX ... SET TABLESPACE does not free disk space

From: Andres Freund <andres(at)anarazel(dot)de>
To: ap(at)zip(dot)com(dot)au, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15582: ALTER TABLE/INDEX ... SET TABLESPACE does not free disk space
Date: 2019-01-09 16:07:28
Message-ID: 20190109160728.cmcnkf4x2hnqb4lr@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

On 2019-01-09 02:21:48 +0000, PG Bug reporting form wrote:
> I've added a tablespace recently to help deal with almost running out of
> disk space.
>
> I then tried to use it with:
>
> ALTER TABLE schema.table SET TABLESPACE hydro2_tmp;
>
> This worked in so far as disk space was used on hydro2_tmp but nothing was
> ever freed in the default location.
>
> I tried a VACUUM FULL but that did not help.
>
> Then I tried moving the indexes belonging to the table but that also did not
> help.
>
> Everywhere I've read and everyone I spoke to said that this is a move
> operation but it appears to be a copy so, unless I missed something, this
> appears to be a bug.
>
> The two table spaces are on separate drives and postgres is from postgres'
> apt repository.

If you restart postgres, is the space freed?

I suspect the issue is that we don't properly close the old relation in
all backends that had it open, but it's hard to know for sure without
that. If restarting isn't feasible, ensuring all backends older than
the move are ended, and issuing a CHECKPOINT; might also free the space
after a few seconds.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David Rowley 2019-01-09 16:34:53 Re: BUG #15577: Query returns different results when executed multiple times
Previous Message Andres Freund 2019-01-09 16:05:33 Re: BUG #15581: CREATE TABLE IF NOT EXISTS error