From 5d3388716527c551a57063f0dabf307952f119cd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E2=80=9CNaeel=E2=80=9D?= Date: Thu, 9 Jul 2026 07:24:08 +0400 Subject: [PATCH] =?UTF-8?q?=D0=94=D0=BE=D0=BA:=20=D0=BA=D0=BE=D0=BD=D1=81?= =?UTF-8?q?=D1=83=D0=BB=D1=8C=D1=82=D0=B0=D1=86=D0=B8=D1=8F=20=D1=81=20?= =?UTF-8?q?=D0=A1=D0=BE=D0=BD=D0=BD=D0=B5=D1=82=D0=BE=D0=BC=20=E2=80=94=20?= =?UTF-8?q?EPERM=20=D0=BD=D0=B5=20PG,=20=D0=BF=D1=80=D0=BE=D0=B1=D0=BB?= =?UTF-8?q?=D0=B5=D0=BC=D0=B0=20=D0=BF=D0=BB=D0=B0=D1=82=D1=84=D0=BE=D1=80?= =?UTF-8?q?=D0=BC=D1=8B?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/sonnet-consult-2026-07-09.md | 33 +++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 docs/sonnet-consult-2026-07-09.md diff --git a/docs/sonnet-consult-2026-07-09.md b/docs/sonnet-consult-2026-07-09.md new file mode 100644 index 0000000..c12666b --- /dev/null +++ b/docs/sonnet-consult-2026-07-09.md @@ -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 и не нашего кода.