PostgreSQL: Дисковий простір не звільнено після TRUNCATE


12

У мене буде TRUNCATEвеличезна таблиця (~ 120Gb) під назвою files:

TRUNCATE files;
VACUUM FULL files;

Розмір таблиці 0, але не було звільнено місця на диску. Будь-які ідеї, як повернути втрачене місце на диску?

ОНОВЛЕННЯ: Дисковий простір було випущено через ~ 12 годин, без жодної дії з мого боку. Я використовую сервер Ubuntu 8.04.


Я збирався запропонувати "вакуумувати його!", Але враховуючи, що ви щойно зробили, я б радив передати це до будь-якого з pg-хакерів чи списків продуктивності pg (і посилання на тему чи відповідь, як тільки ви отримаєте один).
Денис де Бернарді

Чи дає це посилання ( postgresql.1045698.n5.nabble.com/… ) поради для вас? Можливо, ще є щось, що звертається до столу чи подібне.
DrColossos

@DrColossos: Я прочитав коментар у джерелі (коментар, який я зараз не можу знайти), у якому сказано, що PostgreSQL повідомив про всі з'єднання, які збирався відбути усікання, і він заблокував необхідні ресурси. (Є кілька, включаючи саму таблицю, індекси, послідовності та таблиці тостів.) Я впевнений, що знайшов коментар раніше, простеживши через ExecuteTruncate (), але я не на 100% позитивний.
Майк Шеррілл 'Відкликання котів'

Відповіді:


12

Відповідно до коментарів у джерелі , truncateстворює новий, порожній файл зберігання та видаляє старий файл зберігання під час фіксації. (Документи припускають, що "файл зберігання" - це лише файл, що стосується ОС, але я, можливо, не розумію термінологію.)

Створіть новий порожній файл зберігання для відношення та призначте його як значення relfilenode. Старий файл зберігання заплановано на видалення під час фіксації.

Оскільки, здається, видаляється файл, я можу уявити деякі випадки, коли базова операційна система може не одразу звільнити цей простір. Я думаю, що в деяких випадках файл зберігання може потрапити, наприклад, у коробку для переробки під Windows. Але в моєму випадку обрізання таблиці під PostgreSQL 9. щось щось негайно збільшило вільну область під Windows.

Відсікання записується також у журнал WAL. Я не знаю, який ефект це може мати.


2
Можливо, що інший процес запуску все ще має дескриптор файлу до відкритого файлу. Якщо це повториться, я б спробував припинити всі інші бекенд-процеси, просто щоб побачити, чи має це значення.
Пітер Ейзентраут

Я впевнений, що я прочитав, що ExecuteTruncate () повинен переконатися, що цього не може відбутися. Вся частина блокування ресурсів, необхідних для остаточного видалення старого файлу зберігання. Але я не знаю, де я це знайшов у джерелі. Я просто переглядаю його в Інтернеті; легко загубитися таким чином.
Майк Шеррілл 'Відкликання котів'
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.