Referencia técnica independienteSitio oficial
  • Software y sistemas
  • Base de datos

53300

PostgreSQL 53300 en base de datos: se alcanzó el límite de conexiones

Verificada con fuentes2 fuentesRevisada 3 oct 2026
¿Viene un técnico? Mira los 2 pasos que debe enseñarte
Trace

Evidencia vinculada a esta decisión

Ver fuente: PostgreSQL 18 Appendix A: Error Codes

Nivel de riesgo

Atención alta

Comprobaciones mínimas; se recomienda asistencia profesional.

Urgencia

Alta — no esperes

Respuesta rápida

El servidor no admite más conexiones porque se llegó al máximo configurado. Revisa en pg_stat_activity quién ocupa las conexiones y desde cuándo antes de subir el límite; muchas veces sobran sesiones inactivas.

Seguridad primero

Antes de continuar

  • Detente antes de subir max_connections sin más: exige reiniciar el servidor y reserva más memoria. Corrige primero las conexiones que no se cierran.
  • Terminar sesiones aborta lo que estuvieran haciendo. No lo hagas sin saber qué aplicación las usa.

Puedes hacerlo con seguridad

  • Quién ocupa las conexiones
  • Límite frente a lo que piden las aplicaciones
  • Lo que puede hacer quien usa la aplicación

Deja estas tareas a un profesional cualificado

  • No intentes esta tarea profesional: Cerrar sesiones sobrantes de forma controlada
  • No intentes esta tarea profesional: Ajustar max_connections solo con revisión

Lo que un técnico debe poder justificar

Viene un técnico a casa

Estos son los pasos que tiene que hacer y enseñarte. Márcalos mientras trabaja: si se salta pasos, no aceptes el cambio de pieza.

No son instrucciones para que abras o manipules el equipo. Son las comprobaciones que deben sostener una conclusión técnica.

  1. Cerrar sesiones sobrantes de forma controlada

    Qué haceEl DBA identifica sesiones inactivas de una aplicación concreta y, si procede, las termina con pg_terminate_backend tras avisar al equipo.

    Te tiene que enseñarla lista de sesiones terminadas.

    Por escritoel motivo y la corrección en la aplicación.

  2. Ajustar max_connections solo con revisión

    Qué haceSi hace falta más capacidad, el DBA valora la memoria y planifica el reinicio que exige el cambio.

    Te tiene que enseñarvalores antes y después.

    Por escritola prueba de carga.

Antes de aceptar una pieza o reparación

Aún no ha demostrado nada. No aceptes un cambio de pieza solo por el código.

Sigue estos pasos

Aviso: Sigue el orden documentado. Un código identifica el sistema afectado, pero por sí solo no demuestra qué pieza está averiada.

  1. Quién ocupa las conexiones

    Requiere herramientas

    Quién:
    el DBA o administrador.
    Cómo:
    desde una ranura reservada, consulta pg_stat_activity agrupando por usename, application_name y state, con backend_start y xact_start.
    Resultado que importa:
    qué aplicación concentra sesiones y en qué estado.
    Si predominan sesiones idle de una aplicación:
    apunta a conexiones que no se devuelven.
    Si predominan sesiones active:
    indica carga real; revisa consultas lentas antes de tocar el límite.
    Evidencia a conservar:
    resultado agrupado con hora.

    Solo el DBA, usando la ranura reservada. Si no tienes ese acceso, no lo intentes con otras cuentas.

    Evidencia: PostgreSQL connection settings · PostgreSQL 18 cumulative statistics system

  2. Límite frente a lo que piden las aplicaciones

    Sin herramientas especiales

    Quién:
    el equipo de plataforma.
    Cómo:
    suma el máximo de conexiones que puede abrir cada instancia y compáralo con max_connections menos las ranuras reservadas.
    Resultado que importa:
    si la demanda posible supera las ranuras disponibles.
    Si la supera:
    confirma un dimensionado incorrecto; reduce las conexiones por instancia antes de subir el límite.
    Si no la supera:
    descarta el dimensionado y vuelve a las sesiones que no se cierran.
    Evidencia a conservar:
    tabla con instancias, máximos y total.

    Evidencia: PostgreSQL connection settings

  3. Lo que puede hacer quien usa la aplicación

    Sin herramientas especiales

    Quién:
    quien usa la aplicación.
    Cómo:
    si la aplicación muestra este código, espera unos minutos y vuelve a intentarlo una sola vez; si persiste, avisa al soporte con la hora.
    Resultado que importa:
    si el servicio vuelve.
    Si vuelve:
    indica un pico puntual de conexiones.
    Si persiste:
    confirma un problema del servidor que debe resolver el operador.
    Evidencia a conservar:
    hora de cada intento.

    Evidencia: PostgreSQL 18 Appendix A: Error Codes

Situación no resuelta

Si el error persiste, no sigas probando por tu cuenta. Mira qué tiene que hacer y enseñarte el técnico.

Técnico virtual

¿Sigue apareciendo 53300 tras comprobarlo?

Este recorrido usa el código exacto y tus respuestas para elegir una prueba, su resultado esperado y la siguiente bifurcación.

Dónde se aplica este código

Un código solo tiene significado dentro del producto y la versión correctos.

Ámbito principal

Sistema
Software y sistemas
Marca
PostgreSQL
Tipo de producto
Base de datos

Variantes conocidas del código

  • PostgreSQL 53300
  • SQLSTATE 53300
  • too_many_connections

Qué significa

El apéndice A asigna 53300 a too_many_connections, en la clase 53 (recursos insuficientes). max_connections fija cuántas conexiones simultáneas admite el servidor, por defecto 100, y solo cambia al reiniciar. Se reservan ranuras para superusuarios (3 por defecto) y para roles con pg_use_reserved_connections. Subir el límite aumenta la memoria compartida reservada. El código indica que no quedan ranuras, no qué aplicación las ocupa.

Advertencias y condiciones de parada

  • Atención altaadvertencia editorial

    Detente antes de subir max_connections sin más: exige reiniciar el servidor y reserva más memoria. Corrige primero las conexiones que no se cierran.

    Evidencia: PostgreSQL connection settings

  • Precauciónadvertencia editorial

    Terminar sesiones aborta lo que estuvieran haciendo. No lo hagas sin saber qué aplicación las usa.

    Evidencia: PostgreSQL 18 system administration functions

Síntomas y causas

Causas probables · en orden

  • Sesiones que no se cierranFrecuente

    Una aplicación abre conexiones y no las devuelve. En pg_stat_activity aparecen muchas sesiones idle del mismo application_name con backend_start antiguo.

    Evidencia: PostgreSQL 18 cumulative statistics system

  • Más conexiones configuradas que ranurasPosible

    La suma de conexiones que pueden abrir todas las instancias de la aplicación supera max_connections menos las reservadas. Ocurre en picos o al añadir instancias.

    Evidencia: PostgreSQL connection settings

Fuentes y referencias técnicas

  1. 1

    PostgreSQL 18 Appendix A: Error Codes

    PostgreSQL Global Development Group · 2026 · official_doc

  2. 2

    PostgreSQL connection settings

    PostgreSQL Global Development Group · 2026 · official_doc

Fuentes: PostgreSQL 18 Appendix A: Error Codes · PostgreSQL connection settingsrevisado 2026-10-03 · verificado

¿Te ha resultado útil esta ficha?