From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alban Hertroys <alban(dot)hertroys(at)apollovredestein(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Reclaiming space for dropped database |
Date: | 2019-01-23 15:02:01 |
Message-ID: | 26693.1548255721@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Alban Hertroys <alban(dot)hertroys(at)apollovredestein(dot)com> writes:
> Our current development database server is running a bit low on diskspace,
> so I dropped an old but rather large database with the intention of
> claiming back some space. However, the space remains claimed.
> This server was upgraded from PG10 to PG11 using pg_upgrade's --link
> option.
If you used --link, then all the files would remain hard-linked from both
the old and new database directories. You've got to remove them from the
old DB directory as well.
There's not really any point in keeping around the source DB directory
once you've completed a --link migration. Starting the postmaster in
the old DB directory would be disastrous because the files are
inconsistent from its standpoint once the new postmaster has modified
them at all. (In fact, I think pg_upgrade intentionally makes the old
directory non-runnable to prevent that error.) So you might as well
just "rm -rf ./10", not only its biggest subdirectory.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Josef Machytka | 2019-01-23 15:05:32 | Re: PostgreSQL logical replication depends on WAL segments? |
Previous Message | Alban Hertroys | 2019-01-23 12:33:20 | Reclaiming space for dropped database |