PostgreSQL Error 57P02: crash_shutdown — аварийное падение и отладка
- Ошибка в клиенте:
FATAL: the database system is in recovery mode (SQLSTATE 57P02)илиserver closed the connection unexpectedly. - В логах СУБД:
LOG: server process (PID ...) was terminated by signal 9 (or signal 11). - PostgreSQL перезапускает все дочерние процессы и запускает процедуру Redo/Undo восстановления по WAL.
1. Анализ системного журнала ядра на OOM Killer (Signal 9)
dmesg -T | grep -Ei "oom[_-]killer|killed process postgres"Если процесс убит ядром, настройте vm.overcommit_memory = 2 и уменьшите shared_buffers.
2. Поиск аварийных сбоев сегментации (Signal 11 / SIGSEGV)
journalctl -u postgresql -k --since "2 hours ago" | grep -Ei "segfault|core dump"3. Мониторинг процесса Crash Recovery в логах PostgreSQL
tail -n 100 /var/log/postgresql/postgresql-*.logВы увидите сообщения: LOG: database system was not properly shut down; automatic recovery in progress.
4. Проверка целостности файловой системы и оперативной памяти
# Тест RAM
memtester 16G 1
# Проверка SMART дисков
smartctl -a /dev/nvme0n1Частые вопросы (FAQ)
Почему один упавший backend-процесс приводит к перезапуску всего PostgreSQL?
Все дочерние процессы разделяют общую память (shared_buffers). Если один процесс падает аварийно (SIGSEGV/SIGKILL), ядро СУБД не может гарантировать целостность структур shared memory и перезапускает все сессии для безопасного восстановления.
Что делать, если СУБД зависла в режиме Crash Recovery?
Не прерывайте процесс повторным перезапуском. Дождитесь проигрывания всех WAL записей до точки консистентности (checkpoint).
Могут ли сторонние расширения (C-extensions) вызывать ошибку 57P02?
Да, ошибки работы с памятью в C-расширениях (например, PostGIS или кастомных плагинах) часто приводят к сигналу SIGSEGV и crash_shutdown.
Как защитить основной процесс postmaster от Linux OOM Killer?
Задайте параметр OOMScoreAdjust=-1000 в файле конфигурации сервиса systemd (/lib/systemd/system/postgresql.service).
