Док: консультация с Соннетом — EPERM не PG, проблема платформы

2026-07-09 07:24:08 +04:00
parent b3f5c4903e
commit 5d33887165
1 changed files with 33 additions and 0 deletions
@@ -0,0 +1,33 @@
+# Консультация с Соннетом: инцидент 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 и не нашего кода.