Обсуждение: Reclaiming space for dropped database
Hi all, 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. I see this after having dropped the (300+GB) database: -bash-4.2$ du -d 1 -h 4.0K ./.cache 0 ./.config 4.0K ./9.6 376G ./10 72G ./11 447G . The files of that database apparently still exist within the ./10 directory: -bash-4.2$ du -d 1 -h ./10/data/ 4.1G ./10/data/pg_wal 816K ./10/data/global 0 ./10/data/pg_commit_ts 0 ./10/data/pg_dynshmem 8.0K ./10/data/pg_notify 0 ./10/data/pg_serial 0 ./10/data/pg_snapshots 208K ./10/data/pg_subtrans 0 ./10/data/pg_twophase 16K ./10/data/pg_multixact 372G ./10/data/base 0 ./10/data/pg_replslot 0 ./10/data/pg_tblspc 3.5M ./10/data/pg_stat 0 ./10/data/pg_stat_tmp 4.0K ./10/data/pg_logical 96K ./10/data/log 688K ./10/data/pg_xact 376G ./10/data/ How do I reclaim that space? Regards, Alban Hertroys Alban Hertroys D: +31 (0)53 4 888 888 | T: +31 (0)53 4888 888 | E: alban.hertroys@apollovredestein.com Apollo Vredestein B.V.| Ir. E.L.C. Schiffstraat 370, 7547 RD Enschede, The Netherlands Chamber of Commerce number: 34223268 The information contained in this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or action in relation to the contents of this information is strictly prohibited and may be unlawful and request you to delete this message and any attachments and advise the sender by return e-mail. The confidentiality of this message is not warranted. Apollo Vredestein and its subsidiaries rule out any and every liability resulting from this or any other electronic transmission Please consider the environment before printing this e-mail
Alban Hertroys <alban.hertroys@apollovredestein.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
"Tom Lane" <tgl@sss.pgh.pa.us> wrote on 2019-01-23 16:02:01: > Alban Hertroys <alban.hertroys@apollovredestein.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. That explains what I'm seeing. After creating a dump (better safe than sorry), I'll remove that directory. Thanks! Regards, Alban. Alban Hertroys D: +31 (0)53 4 888 888 | T: +31 (0)53 4888 888 | E: alban.hertroys@apollovredestein.com Apollo Vredestein B.V.| Ir. E.L.C. Schiffstraat 370, 7547 RD Enschede, The Netherlands Chamber of Commerce number: 34223268 The information contained in this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or action in relation to the contents of this information is strictly prohibited and may be unlawful and request you to delete this message and any attachments and advise the sender by return e-mail. The confidentiality of this message is not warranted. Apollo Vredestein and its subsidiaries rule out any and every liability resulting from this or any other electronic transmission Please consider the environment before printing this e-mail
Tom Lane <tgl@sss.pgh.pa.us> writes: > Alban Hertroys <alban.hertroys@apollovredestein.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 Yeah. IIRC, it renames control to pg_control.old to avoid accidental startup. > just "rm -rf ./10", not only its biggest subdirectory. > > regards, tom lane > > -- Jerry Sievers Postgres DBA/Development Consulting e: postgres.consulting@comcast.net