Ответ
По умолчанию PostgreSQL сохраняет WAL (Write-Ahead Log) файлы до тех пор, пока они не будут архивированы или удалены. Время жизни WAL не ограничено жестко часами, но зависит от настройки wal_keep_segments (или wal_keep_size в PostgreSQL 13+) и max_wal_size.
Если архивация WAL (archive_mode = on) включена, файлы удаляются после успешной архивации. Без архивации WAL могут накапливаться, пока не достигнут max_wal_size (по умолчанию 1GB), после чего старые сегменты удаляются.
Пример настройки в postgresql.conf:
wal_keep_size = 1024MB # сохранять минимум 1GB WAL
max_wal_size = 4GB # максимум перед checkpointОтвет 18+ 🔞
А, блядь, про эти WAL-файлы в Постгресе! Ну это же классика, ёпта. Ситуация, от которой у админа волосы дыбом встают, когда он смотрит на диск и видит, что его сожрали какие-то ёбаные логи.
Смотри, тут история такая. По умолчанию, этот самый PostgreSQL — он как та белка в колесе, сука. Он пишет эти WAL-файлы (это типа журнал всех операций, чтоб если что — откатиться можно было) и хранит их до посинения. То есть, грубо говоря, время жизни у них не ограничено какими-то там часами, как в других системах. Он их просто так не выкинет, хитрая жопа.
Всё упирается в две главные настройки, чувак. Первая — это wal_keep_segments (а в новых версиях, с тринадцатой, её переименовали в wal_keep_size). Это типа минимальный запас, который он обязан держать, даже если они уже не нужны. На случай, если какой-нибудь реплика-полупидор отстала и ей надо догнать. Поставил мало — риск, что реплика отвалится. Поставил много — жрёт место, как не в себя.
А вторая — это max_wal_size. Вот это уже поинтереснее. Это как порог терпения, блядь. Представь: Постгрес пишет, пишет эти логи, накапливает их. Как только их набирается на этот самый max_wal_size (по дефолту там 1GB, смех да и только), он такой: «Всё, терпения ноль, ебать! Хватит!» — и запускает процесс checkpoint. А после этого старые, уже отработанные сегменты WAL он спокойно, без зазрения совести, отправляет нахуй, то есть удаляет.
Но есть ещё один хитрый сценарий — архивация. Если ты включил archive_mode = on, то для Постгреса наступает рай. Он каждый WAL-файлик, как только он заполнился, с любовью отдаёт на архивацию (в S3, на другой диск, куда ты там настроил). И после того, как архивация прошла успешно, он с чистой совестью этот файл стирает с основного диска. Красота! Проблема в одном: если твой скрипт архивации сдох или целевое хранилище накрылось медным тазом, то эти файлы будут копиться, как сумасшедшие, пока весь диск не забият. Вот тогда и начинается «ёперный театр» с алёртами и ночными побудками.
Короче, чтобы не было пиздеца, в конфиге postgresql.conf нужно эти штуки настроить вменяемо. Вот смотри, примерно так:
wal_keep_size = 1024MB # Минимум 1GB WAL пусть держит, чтоб реплики не ныли
max_wal_size = 4GB # Максимум перед тем, как он взъебится и сделает checkpointВыставил max_wal_size в 4GB — значит, как только WAL-ов наберётся примерно на четыре гига, он скажет «доверия ебать ноль» к твоему диску и начнёт прибираться. А wal_keep_size в 1GB — это как страховочная сетка для отстающих потребителей этих логов.
Главное — мониторь место на диске, где pg_wal лежит. А то придёт день, когда ты увидишь No space left on device, и тогда будет тебе, прости господи, и Хиросима, и Нагасаки в одном флаконе.
