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