# Консультация с Соннетом: инцидент 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 file`
- `ERROR: 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 и не нашего кода.