Re: After upgrade to 9.5 space not being released - Mailing list pgsql-bugs

From Jeff Janes
Subject Re: After upgrade to 9.5 space not being released
Date
Msg-id CAMkU=1xFvm0Fpr2Lykfu5jCO2mtg1YXG7y4VkZob5ubk4w8FgA@mail.gmail.com
Whole thread Raw
In response to Re: After upgrade to 9.5 space not being released  (Ganesh Kannan <ganesh.kannan@weatheranalytics.com>)
List pgsql-bugs
On Fri, Jun 3, 2016 at 1:17 PM, Ganesh Kannan
<ganesh.kannan@weatheranalytics.com> wrote:
>
> I have to ask this out of curiosity... not removing the 9.4 data director=
ies explains why the space was not released. However, why did I not see the=
 same issue with Index tablespace directories. I have about 4 TB of indexes=
 and the vols were pretty much 90% utilized before the "alter table set log=
ged", and may be 95% or so after running the statement. Does the switch fro=
m "unlogged" to "logged" of tables has a different effect on indexes - may =
be indexes are not "really" rebuilt as were the tables.

When a relation is removed, any datafiles after the first one are
immediately unlinked.  But that leaves the old directory with links to
full-sized files.

But the first datafile of each is treated differently, it is first
truncated to zero size, and then not unlinked until the next
checkpoint completes.  Truncating via one hard link of course reduces
the size as "seen" by the other hard link, too, so that space gets
freed.

So if most of your indexes are less than 1 gig, the space used by
those indexes will get freed via truncation, while the larger tables
will only have the first gig freed.

That's my theory, anyway.

Cheers,

Jeff

pgsql-bugs by date:

Previous
From: taylor.reece@zuerchertech.com
Date:
Subject: BUG #14177: ARRAYs in VIEWs are inconsistently cast
Next
From: Tom Lane
Date:
Subject: Re: BUG #14134: segmentation fault with large table with gist index