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