Tecnología · GUÍA PRÁCTICA
¿PostgreSQL dice “remaining connection slots are reserved”? Cree un registro de propietarios antes de cerrar sesiones
Demuestre el presupuesto de conexiones de usuario, agrupe backends por aplicación y edad, frene nuevas conexiones y cierre solo un propietario obsoleto verificado.
Este FATAL es una decisión de admisión, no prueba que cada backend sea una fuga. Al agotarse la capacidad ordinaria PostgreSQL protege slots reservados; las conexiones existentes pueden ser peticiones activas, pool idle, idle in transaction, replicación o procesos internos.
Conserve el error y la ventana temporal, detenga el crecimiento de conexiones y cree un registro de propietarios de solo lectura. El registro, no una lista de PID, decide esperar, cancelar, terminar, reducir el pool o cambiar capacidad.
Demuestre el presupuesto de admisión
Registre mensaje, versión, proveedor, endpoint y primer fallo. Desde una conexión de emergencia autorizada lea los tres parámetros sin asumir valores predeterminados.
Calcule capacidad y headroom de usuario y separe clientes, procesos internos y replicación. Sin ruta de emergencia use el control plane o soporte documentado del proveedor.
Cree un registro, no un volcado de PID
Agrupe por database, user, application_name, client, backend type y state; conserve el backend, la transacción y el cambio de estado más antiguos.
Un application_name vacío es una brecha de observabilidad. Correlacione dirección, réplicas y configuración del pool antes de asignar propietario.
Clasifique antes de actuar
Un backend active puede servir peticiones; idle puede ser inventario sano; idle in transaction exige escalar al propietario, pero no prueba abandono.
Primero frene la fuente: worker desbocado, autoscaling, tormenta de reintentos o una réplica, según el runbook.
Elija la recuperación más estrecha
Espere trabajo activo corto si es seguro; cancele solo si la aplicación lo tolera; termine la sesión únicamente con propietario, impacto y condición obsoleta verificados.
Si hay demasiados clientes legítimos, reduzca pools por proceso, limite lifetime y use un pooler aprobado. Sume réplicas, jobs, herramientas y migraciones.
Verifique y evite la recurrencia
Tras la acción confirme headroom, nueva admisión, conteos estables y ausencia de recarga inmediata; compare el registro antes y después.
Alerte por headroom, crecimiento por propietario, transacción más antigua y espera del pool. La salida exige fuente limitada y capacidad estable.
