Настройка WAL и checkpoint

Discord: 100K сообщений/секунду в PostgreSQL. Дефолтный synchronous_commit = on. TPS = 12K. После synchronous_commit = off для счётчиков присутствия и read receipts - TPS = 190K. Те же 5 строк конфига. Понимание WAL-параметров - разница между арендой 10 серверов и использованием 1.

• **Discord** - synchronous_commit=off для non-critical data (presence, read receipts): 15x рост TPS без изменения кода приложения
• **GitLab** - max_wal_size = 4 ГБ, checkpoint_timeout = 15 мин: снижение I/O spikes во время checkpoint на 70%, стабильный latency P99
• **AWS RDS** - автоматически настраивает wal_buffers, max_wal_size и checkpoint параметры при изменении класса инстанса

wal_buffers: буфер записи WAL

**wal_buffers** - область shared memory для буферизации WAL-записей перед сбросом на диск. WAL writer сбрасывает буфер на диск при COMMIT транзакции или при заполнении буфера. Дефолт: -1 (автовычисление = 1/32 от shared_buffers, максимум 64 МБ). При высоком OLTP обычно достаточно.

**synchronous_commit** влияет на wal_buffers: при synchronous_commit=off PostgreSQL не ждёт fsync WAL при COMMIT. Транзакция подтверждается клиенту до сброса WAL на диск. Быстрее, но при сбое возможна потеря последних ~200 мс транзакций. Подходит для некритичных данных (счётчики, статистика).

Checkpoint: настройка сброса dirty pages

**Checkpoint** - периодический сброс всех dirty pages из shared_buffers на диск. После checkpoint WAL до этой точки можно удалить (не нужен для recovery). Проблема: наивный checkpoint сбрасывает всё сразу - I/O spike. checkpoint_completion_target растягивает запись на 90% checkpoint_timeout.