Thread: How to recover space from a failed cluster
I have a postgres 8.1 database running under FC4 x86_64. While I was clustering a table, the machine died (kernel/hardware issue). When I restarted the machine, the space used by postgres during the cluster operation was still in use. I would like to release this space and reissue the cluster. Figuring that a vacuum may release the space, I started a "vacuum verbose" on the database a couple of days ago. It produced a few messages shortly after starting the vacuum but there are no new progress messages for over two days and I am becoming impatient. The postgres vacuum process is currently pinned at 80%. I am wondering if the vacuum is still occurring or is it stalled? How far along is it? Is there another way of releasing this space short of doing a dump+restore. Here are the messages generated thus far by postgres:
INFO: "big_data6": found 0 removable, 333573644 nonremovable row versions in 34451403 pages
DETAIL: 0 dead row versions cannot be removed yet.
Nonremovable row versions range from 132 to 2032 bytes long.
There were 0 unused item pointers.
Total free space (including removable row versions) is 15031961828 bytes.
0 pages are or will become empty, including 0 at the end of the table.
23010625 pages containing 13911976044 free bytes are potential move destinations.
CPU 1457.42s/217.69u sec elapsed 11557.92 sec.
INFO: index "big_data6_detid_key" now contains 333573644 row versions in 914628 pages
DETAIL: 0 index pages have been deleted, 0 are currently reusable.
CPU 58.03s/10.28u sec elapsed 383.37 sec.
INFO: index "big_data6_region_detid" now contains 333573644 row versions in 914628 pages
DETAIL: 0 index pages have been deleted, 0 are currently reusable.
CPU 54.70s/9.62u sec elapsed 348.09 sec.
Thanks.
INFO: "big_data6": found 0 removable, 333573644 nonremovable row versions in 34451403 pages
DETAIL: 0 dead row versions cannot be removed yet.
Nonremovable row versions range from 132 to 2032 bytes long.
There were 0 unused item pointers.
Total free space (including removable row versions) is 15031961828 bytes.
0 pages are or will become empty, including 0 at the end of the table.
23010625 pages containing 13911976044 free bytes are potential move destinations.
CPU 1457.42s/217.69u sec elapsed 11557.92 sec.
INFO: index "big_data6_detid_key" now contains 333573644 row versions in 914628 pages
DETAIL: 0 index pages have been deleted, 0 are currently reusable.
CPU 58.03s/10.28u sec elapsed 383.37 sec.
INFO: index "big_data6_region_detid" now contains 333573644 row versions in 914628 pages
DETAIL: 0 index pages have been deleted, 0 are currently reusable.
CPU 54.70s/9.62u sec elapsed 348.09 sec.
Thanks.
s anwar <sanwar@gmail.com> writes: > I have a postgres 8.1 database running under FC4 x86_64. While I was > clustering a table, the machine died (kernel/hardware issue). When I > restarted the machine, the space used by postgres during the cluster > operation was still in use. That would be in the form of a file that's not referenced by any value of pg_class.relfilenode. I think you have to find and delete the file by hand --- there is not any automated mechanism for this. See http://www.postgresql.org/docs/8.1/static/storage.html regards, tom lane