2.5 KiB
2.5 KiB
Консультация с Соннетом: инцидент 2026-07-08 (продолжение)
Вопрос 1: Может ли PG быть повреждён после OOM при нормальных метриках?
Да, может. Сценарий:
- OOM при активной записи → WAL-запись оборвана на середине
- PG поднялся, прошёл recovery по WAL, считает себя здоровым
- Grafana показывает метрики процесса PG — они нормальные
- Но на уровне отдельных relation-файлов могут быть битые страницы, которые проявляются только при обращении к конкретной таблице/индексу
EPERM при connect() — это не PG-уровневая ошибка, это OS/сеть. PG повреждение дало бы ECONNRESET, 53300 (too many connections), или ошибку внутри сессии. Если EPERM именно на connect() — смотри в сторону сети/платформы, не PG internals.
Вопрос 2: Достаточно ли разницы PG для объяснения?
Нет. EPERM на connect() — это не симптом повреждённого PG. Повреждённый PG дал бы:
FATAL: could not open fileERROR: invalid page in block- Или просто отклонял бы соединения с ошибкой pg-level
EPERM — это ядро Linux отказывает в системном вызове connect(). PG здесь ни при чём. Ищи причину на стороне Node.js процесса или платформы.
Вопрос 3: Мог ли managed-сервис перегенерировать credentials при recovery?
Да, это распространённая практика у managed PG — при recovery (особенно из backup/snapshot) могут:
- Сброситься пароли к дефолтным
- Создаться новый пользователь вместо старого
- Измениться SSL CA-сертификат
Как проверить без прямого доступа — через /v2/db-status (уже есть в коде)
Ключевой вывод
EPERM на connect() — проблема сети/платформы, не PG и не нашего кода.