Як повернути простір, узятий індексом, який частково побудований і припинений відключенням електроенергії

Я запускаю postgres (postgis) 9.4.2 на mac (10.10.4).

У мене є кілька великих столів (кілька туберкульозів).

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

Я спробував скинути стіл і повторно в'їсти, і це не втратило місця. Тепер я перебуваю на місці, де мені не вистачає місця для складання індексу.

Чи застрягли файли, згенеровані під час збирання індексу, у якійсь новій частині, де система їх не може видалити через те, як машина вийшла з ладу під час відключення живлення?

Коли я дивлюся на розміри таблиць + індекси в db (що є єдиними даними на цьому диску), вони складають приблизно 6TB . Привід становить 8 ТБ , і на диску він залишився менше 500 Гб , тому, здається, десь втрачено близько 1,5 ТБ, що приблизно за розмір, який би був індекс.

Будь-які ідеї?

Зазвичай ми очікували, що при перезапуску постгресів процес відновлення аварійних ситуацій видалить з каталогу даних файли, пов’язані з відкатним індексом.

Припустимо, що це не спрацювало, або принаймні, що його потрібно перевірити вручну.

Перелік файлів, які мають бути у datadir, можна встановити таким запитом:

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 в 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 Гб. Якщо затяжні сегменти не прикріплені ні до чого, їх слід розглядати окремо)

і відрізняйте цей файл із результатом запиту, наведеним вище.

Якщо є тривалі файли даних, які не відповідають жодному об'єкту, про який знає db, вони повинні відображатись у цій різниці.