テクノロジー · 実用ガイド
PostgreSQL の「remaining connection slots are reserved」—セッションを切る前に所有者台帳を作る
一般ユーザーの接続予算を証明し、application と age で backend を集計し、新規流入を止めてから確認済みの stale owner だけを終了します。
この FATAL は admission decision であり、すべての backend が leak だという証拠ではありません。通常ユーザー枠を使い切ると reserved slot が保護され、既存接続には active request、idle pool、idle in transaction、replication、internal process が含まれます。
error と time window を保存し、新規接続の増加を止め、read-only の owner ledger を作ります。wait、cancel、terminate、pool 縮小、capacity 変更は PID 一覧ではなく台帳で決めます。
admission budget を証明
error、version、provider、endpoint、最初の failure time を記録し、認可済み emergency connection で3設定を読みます。
通常ユーザー予算と headroom を計算し、client backend、internal process、replication を分離します。緊急経路がない場合は provider の control plane または support を使います。
PID ではなく owner ledger
database、user、application_name、client、backend type、state で集計し、最古の backend、transaction、state-change time を保持します。
空の application_name は観測不足です。client address、replica 数、pool 設定で owner を確認し、IP や idle だけで終了しません。
行動前に分類
active は request 処理中かもしれず、idle は正常な pool、idle in transaction は迅速な owner escalation が必要です。
runbook に従い runaway worker、autoscaling、retry storm、replica からの新規流入を先に止めます。
最小の復旧を選ぶ
短い active work は安全なら待ち、application が cancel を処理できる場合だけ query を取消し、owner と影響が確認済みの場合だけ session を終了します。
正当な client が多いなら per-process pool と lifetime を縮小し、承認済み pooler を使います。すべての replica、job、tool を合計します。
復旧を検証し再発防止
action 後に headroom、新規 admission、active count、即時 refill を確認し、前後の台帳を比較します。
headroom、owner growth、oldest transaction、pool wait を監視し、leak source が制限され capacity が安定して初めて完了です。
