Как освободить место, занятое индексом, который частично построен и был прерван отключением электроэнергии

Я использую Postgres (Postgis) 9.4.2 на Mac (10.10.4).

У меня есть пара больших столов (несколько ТБ).

Во время построения индекса для одного из них, который занимает около недели, я наблюдал падение доступного места на жестком диске, поскольку можно было ожидать, что он приблизится почти к той точке, в которой индекс будет завершен, когда перебои в подаче электроэнергии продолжались дольше, чем блок батареи и система. пошел вниз У меня были отключены буферы, и fillfactor=100во время сборки, так как это статический источник данных. При перезагрузке доступное пространство, оставшееся на диске, находится именно там, где оно было почти в конце построения индекса. Вакуумный анализ не освобождает пространство.

Я попытался уронить стол и снова проглотить, и это не оставило места. Сейчас я нахожусь в месте, где мне не хватает места для построения индекса.

Не застряли ли файлы, сгенерированные во время построения индекса, в каком-то подвешенном состоянии, где они не могут быть удалены системой из-за того, как машина вышла из строя во время отключения питания?

Когда я смотрю на размеры таблиц и индексы в БД (которые являются единственными данными на этом диске), они составляют примерно 6 ТБ . Объем накопителя составляет 8 ТБ , а на диске осталось менее 500 ГБ , поэтому кажется, что где-то потеряно около 1,5 ТБ , что примерно соответствует размеру индекса.

Любые идеи?

Обычно мы ожидаем, что при перезапуске postgres процесс восстановления после сбоя удалит файлы, связанные с индексом отката, из каталога данных.

Давайте предположим, что это не сработало, или, по крайней мере, это нужно проверить вручную.

Список файлов, которые должны быть в каталоге данных, может быть создан с помощью запроса:

select pg_relation_filenode(oid)
   from pg_class
  where relkind in ('i','r','t','S','m')
    and reltablespace=0
  order by 1;

reltablespace=0для табличного пространства по умолчанию. Если проблемный индекс был создан в табличном пространстве не по умолчанию, его 0необходимо заменить на его OID in pg_tablespace.

i, r, t, S, m relkindсоответствуют соответственно индексам, таблицам, пространству тостов, последовательностям, материализованным представлениям. Все эти объекты имеют свои данные в файлах, имена которых совпадают pg_relation_filenode(oid).

На диске файлы данных находятся ниже, $PGDATA/base/oid/где oidнаходится oidбаза данных, полученная с помощью select oid,datname from pg_database. Если мы не говорим о табличном пространстве по умолчанию, baseвместо PG_version_somelabelнего вместо.

Вывести список и отсортировать файлы, соответствующие relfilenodes в этом каталоге:

ls | grep -E '^[0-9]+$' | sort -n > /tmp/list-of-relations.txt

(это фактически сохраняет только первый сегмент для отношений, которые больше чем 1 ГБ. Если есть задерживающиеся сегменты, ни к чему не привязанные, их следует рассматривать отдельно)

и измените этот файл с результатом запроса выше.

Если существуют устаревшие файлы данных, которые не соответствуют ни одному объекту, о котором знает БД, они должны появиться в этом diff.