Re: Table space not returned to the OS ?

From: Florents Tselai <florents(dot)tselai(at)gmail(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Table space not returned to the OS ?
Date: 2022-06-27 09:53:06
Message-ID: F90073A7-76BC-471D-870E-9ABF187B773C@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> On 27 Jun 2022, at 12:38 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>
>
>
> On Mon, Jun 27, 2022 at 11:30 AM Florents Tselai <florents(dot)tselai(at)gmail(dot)com <mailto:florents(dot)tselai(at)gmail(dot)com>> wrote:
> Hi,
>
> A few months back (October) I had upgraded a Postgres instance from v12 —> 14.
>
> The database disk size under /var/lib/postgresql/12 was around 800GB+ back then.
> Note, that IIRC I had used hard-linking during the upgrade.
>
> In the database itself, lots of things have changed since.
> In fact, that database itself has been dropped at some point and restored from a backup.
>
> As I was running out of disk space, I started investigating and found out that
>
> /var/lib/postgresql/12/main/base/16385 —> 886GB+
> /var/lib/postgresql/14 —> 400GB
>
> The last modification date on that directory (../12/) appears to be around a month ago,
> When the table with relied 16385 was in fact dropped.
>
> Now, In my update scripts (I use this db as an OLAP) I occasionally run VACUUM.
>
> Is it weird that the 886GB space hasn’t been returned to the OS yet?
>
> What’s the safest way to return it to the OS manually?
>
>
> When you use hardlinks in the upgrade all the files remain in the old directory when they are removed from the new one such as when you drop a relation. it is there for emergency recoveries. It's only the contents of the files that's "mirrored", not the existance.
>
> It looks like you didn't actually delete the old cluster, which you are supposed to do once you have verified that the new one works. This looks like a debian/ubuntu system, which means you probably forgot to run "pg_dropcluster 12 main"? Or if it's not a debian cluster, the equivalent of that which results in

Ah, you’re right
pg_dropcluster 12 main && systemctl daemon-reload
worked fine.

Thanks.

> removing the data directory for 12 along with any configuration files it has elsewhere.
>
> --
> Magnus Hagander
> Me: https://www.hagander.net/ <http://www.hagander.net/>
> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Laurenz Albe 2022-06-27 10:01:41 Re: Table space not returned to the OS ?
Previous Message Özge Özyavuz 2022-06-27 09:50:17 help for pg_wal issue