¿Cómo finalizo las consultas de larga duración en mi instancia de base de datos den Amazon RDS para PostgreSQL o Aurora compatible con PostgreSQL?

Descripción corta

Según tu caso de uso, puedes usar la función pg_cacnel_backend(pid) o pg_terminate_backend(pid).

Usa la función pg_cancel_backend(pid) para enviar una señal SIGINT a un proceso de backend específico y cancelar la consulta actual de larga duración. Durante este proceso, la conexión a la base de datos permanece activa. El backend puede continuar procesando otras consultas o transacciones después de que la función termine correctamente la consulta actual.

Utiliza la función pg_terminate_backend(pid) para finalizar una consulta y cerrar la conexión. Utiliza esta función para enviar una señal SIGTERM a un proceso de backend específico y terminar forzosamente la conexión asociada al proceso. Este proceso se revierte y libera las transacciones abiertas o los bloqueos retenidos dentro de la conexión.

Para obtener más información, consulta Funciones de señalización del servidor en el sitio web de PostgreSQL.

Nota: Algunas versiones de Aurora compatibles con PostgreSQL no pueden finalizar un proceso de autovacuum, incluso si se cumplen todos los requisitos del sistema. Al intentar finalizar un proceso de autovacuum en estas versiones, es posible que recibas el siguiente mensaje de error:

"ERROR: 42501: must be a superuser to terminate superuser process LOCATION: pg_terminate_backend, signalfuncs.c:227."

Algunas versiones secundarias permiten al rds_superuser finalizar los procesos de autovacuum que no están asociados explícitamente a un rol. Para comprobar si tu versión permite alrds_superuser finalizar los procesos de autovacuum, consulta Actualizaciones de Amazon Aurora PostgreSQL.

Resolución

Para usar pg_cacnel_backend(pid) o pg_terminate_backend(pid), debes ser uno de los siguientes usuarios:

• Eres un rds_superuser o un miembro del rol predeterminado pg_signal_backend.
• Tienes conexión a la base de datos como el mismo usuario de base de datos de la sesión que deseas cancelar.

Para finalizar la consulta de larga duración, debes tener el ID de proceso (PID) de la transacción. Para encontrar el PID, ejecuta la consulta pg_stat_activity y consulta la columna pid. Para obtener más información, consulta pg_stat_activity en el sitio web de PostgreSQL.

Uso de la función pg_cancel_backend(pid)

Cuando ejecutas el siguiente comando desde otra sesión, la función usa el PID de la consulta de larga duración para cancelar la consulta desde el backend de la base de datos:

SELECT pg_cancel_backend(8121);

Nota: En el comando anterior, el PID de la consulta es 8121.

Resultado esperado:

pg_cancel_backend
 ------------------------
 t

En el resultado anterior, el valor t de «true» muestra que la función canceló la consulta. Si la consulta ya no existe o no hay una conexión de base de datos activa, el resultado muestra un valor f para «false».

Uso de la función pg_terminate_backend(pid)

Al ejecutar el siguiente comando desde una sesión diferente, la función finaliza la conexión a la base de datos con el pid 8121:

SELECT pg_terminate_backend(8121);

Resultado esperado:

pg_terminate_backend
------------------------
 t

El resultado anterior muestra t aunque la función no canceló la consulta. La respuesta muestra que la función envió correctamente la señal SIGTERM. La función no interrumpe inmediatamente el proceso de backend. Para mantener la memoria compartida en un estado uniforme, el comando inicia un proceso de apagado correcto durante CHECK_FOR_INTERRUPTS.

Cancelación de un proceso de larga duración que no termina

Cuando ejecutas pg_cancel_backend(pid) o pg_terminate_backend(pid) en una sección interrumpible, las funciones no pueden cancelar la consulta. Por ejemplo, el proceso intenta adquirir un bloqueo ligero. O bien, el proceso está esperando a que se complete una llamada al sistema de lectura o escritura desde el almacenamiento. En estos casos, el proceso de backend no recibe la señal de cancelación y el proceso se detiene indefinidamente.

Si el proceso no responde a los métodos de cancelación, reinicia todo el motor de base de datos y finaliza forzosamente el proceso estancado.

Se recomienda ajustar los parámetros de tiempo de espera, como statement_timeout, idle_in_transaction_session_timeout y idle_session_timeout para las versiones 14 y posteriores de PostgreSQL. También se recomienda configurar los tiempos de espera del lado del cliente y del servidor, como tcp_keepalives_idle, tcp_keepalives_interval y tcp_keepalives_count.

Nota: Como estos parámetros de tiempo de espera son dinámicos, no es necesario reiniciar la base de datos para que se produzcan cambios.

Configura los parámetros en función de tus requisitos. Por ejemplo, puedes establecer los parámetros en los siguientes niveles:

• El nivel de instrucción individual para consultas específicas
• El nivel de usuario para todas las consultas de un usuario específico
• El nivel de base de datos para controlar el comportamiento en toda una base de datos
• El nivel de grupo de parámetros de instancia para establecer la configuración global

Nota: Dado que un tiempo de espera breve cancela las consultas intencionales de ejecución prolongada, no establezcas un tiempo de espera breve a nivel de instancia o base de datos. Si estableces log_min_error_statement en ERROR o en un valor inferior, Amazon RDS registrará la instrucción en la que se agotó el tiempo de espera. Para obtener más información, consulta Statement behavior (Comportamiento de las instrucciones) en el sitio web de PostgreSQL.

Información relacionada

¿Cómo puedo comprobar las consultas en ejecución y diagnosticar los problemas de consumo de recursos para mi instancia de base de datos de Amazon RDS para PostgreSQL o Aurora PostgreSQL?

¿Cómo puedo identificar y solucionar los problemas de rendimiento y las consultas de ejecución lenta en mi instancia de base de datos compatible con Amazon RDS para PostgreSQL o Aurora PostgreSQL?