Как стать автором
Обновить

Комментарии 3

Корректный способ — штатный перезапуск базы.
При crash recovery временные файлы база оставляла на диске намеренно, а не «забывала». Разработчики считали, что эти файлы могут быть полезны для дебага краха СУБД.
Я пишу об этом в прошедшем времени, т.к. в марте это поведение было изменено и postgresql 14 будет вычищать эти временные файлы сам при crash recovery, так же как и при обычном старте.
Корректный способ — штатный перезапуск базы.
Это идеальный, но не всегда допустимый вариант:
1. Если простой базы/ее рестарт приводит к дополнительной трате ресурсов, ошибкам в приложениях, потере денег,… Это не всегда оправдано повторно, даже если сервер уже выключался перед этим аварийно.
2. Как правильно сказано в описании к тому же патчу, само наличие этих файлов может усугублять проблему "disk usage may grow over time due to repeated backend failures (possibly
even hitting ENOSPC)"
.
Да, об этом десятке секунд даунтайма на рестарт базы бывает проблемно договориться. Но и потери в (далеко не самом невозможном) случае «упс, я ошибся в команде и грохнул не тот файл» будут куда больше.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий