Postgres не освободил место для ОС после TRUNCATE таблицы 145 ГБ - PullRequest
2 голосов
/ 25 апреля 2019

Сегодня я обрезал таблицу на 145 ГБ, но пространство не вернулось в ОС. Я уже проверил внутри базы данных, и таблица теперь пуста.

Несмотря на то, что пространство не было освобождено для ОС, я заметил, что при запуске команды du в разделе уже сообщается о 145 ГБ меньше, но когда я запускаю df -h, это не так. Расхождение в 145 ГБ не может быть из-за размера инода.

Я использую сервер Mirth с базой данных Postgres 9.3 в CentOS 7.

Любая подсказка, почему не освободилось место?

Ответы [ 2 ]

3 голосов
/ 25 апреля 2019

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

См. Следующий комментарий в ExecuteTruncateGuts:

/*
 * Need the full transaction-safe pushups.
 *
 * Create a new empty storage file for the relation, and assign it
 * as the relfilenode value. The old storage file is scheduled for
 * deletion at commit.
 */

Но поскольку вы говорите, что du больше не сообщает о пробеле, должно иметь место одно из следующих условий:

  • Транзакция, запустившая TRUNCATE, все еще открыта.

  • У чего-то еще есть открытый файл.UNIX фактически не удаляет файл, пока последняя (жесткая) ссылка на него не исчезнет и последний процесс не закроет его.Симптом состоит в том, что df показывает, что файл все еще там, но du не перечисляет его.

0 голосов
/ 25 апреля 2019

Когда вы удаляете или усекаете таблицу, PostgreSQL не возвращает свое пространство в ОС
Он просто помечает каждую строку как "удаленную".
Когда вы вставляете новую строку, PostgreSQL повторно использует "удаленное" пространствохранить новые данные.

Чтобы освободить такое «удаленное» пространство, вы должны использовать VACUUM FULL
https://www.postgresql.org/docs/devel/sql-vacuum.html

...