Comment puis-je mettre fin aux requêtes de longue durée dans mon instance de base de données Amazon RDS pour PostrgreSQL ou Aurora compatible avec PostgreSQL ?

Brève description

Utilisez pg_cancel_backend(pid) pour mettre fin à une requête tout en maintenant la connexion active. Utilisez pg_terminate_backend(pid) pour mettre fin à une requête et fermer la connexion. Cette fonction met fin à la connexion complète et peut affecter les autres requêtes en cours. Utilisez pg_terminate_backend(pid) uniquement lorsque cela est nécessaire.

Pour utiliser les fonctions, vous devez disposer de l'une des autorisations suivantes :

• Vous êtes un rds_superuser ou un membre du rôle par défaut pg_signal_backend.
• Vous êtes connecté à la base de données en tant qu'utilisateur de base de données ayant participé à la session que vous souhaitez annuler.

Remarque :

• Utilisez la colonne pid de la vue pg_stat_activity pour trouver l'ID de processus (PID) d'un processus de backend actif. Pour plus d'informations, consultez la page pg_stat_activity sur le site Web de PostgreSQL.
• **pg \ _signal \ _backend ** envoie le signal SIGINT et pg_terminate_backend envoie le signal SIGTERM au processus de backend. Pour plus d'informations, consultez la page Fonctions de signalisation du serveur sur le site Web de PostgreSQL.

Résolution

Remarque : Certaines versions compatibles avec Aurora PostgreSQL ne peuvent pas mettre fin à un processus d’autovacuum, même lorsque toutes les exigences du système sont satisfaites. Lorsque vous essayez de mettre fin à un processus d’autovacuum dans ces versions, l'erreur suivante peut s'afficher :

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

Certaines versions mineures permettent à rds_superuser de mettre fin aux processus d’autovacuum qui ne sont pas explicitement associés à un rôle. Pour vérifier si votre version autorise rds_superuser à mettre fin aux processus d'autovacuum, consultez les mises à jour d'Amazon Aurora PostgreSQL.

Voici quelques exemples des fonctions pg_cancel_backend(pid) et pg_terminate_backend(pid) utilisées :

pg_cancel_backend(pid)

Lorsque vous exécutez la fonction suivante à partir d’une autre session, elle annule la requête exécutée à partir du backend de base de données avec le pid 8121

postgres=> SELECT pg_cancel_backend(8121);

Résultat attendu :

pg_cancel_backend
------------------------
 t
(1 row)

Lorsque vous exécutez la commande suivante, la requête est correctement annulée, la fonction renvoie la valeur vrai (t). Si la requête n'existe plus ou si la connexion à la base de données n'existe pas, la fonction renvoie la valeur faux (f).

pg_terminate_backend(pid)

Lorsqu'elle est exécutée à partir d’une autre session, la fonction suivante met fin à la connexion à la base de données avec le pid 8121.

postgres=> SELECT pg_terminate_backend(8121);

Résultat attendu :

pg_terminate_backend
------------------------
 t
(1 row)

La fonction renvoie la valeur vrai (t), même si le processus n'est pas encore annulé. La réponse indique uniquement que le signal SIGTERM a été envoyé avec succès. La commande n'interrompt pas immédiatement le processus de backend. Pour maintenir la mémoire partagée dans un état incohérent, la commande lance un processus d'arrêt progressif qui se produit pendant CHECK_FOR_INTERRUPTS.

Annuler un processus de longue durée qui ne s'arrête pas

Lorsque vous exécutez pg_cancel_backend(pid) et pg_terminate_backend(pid) dans une section interruptible, les fonctions n'annulent pas correctement la requête. Par exemple, le processus peut attendre d'acquérir un verrou léger ou un appel du système de lecture/écriture sur un périphérique de stockage réseau. Le processus de backend n'est pas signalé et se bloque indéfiniment.

Pour terminer le processus, redémarrez le moteur de base de données.

Il est recommandé de régler les paramètres de délai d'attente, tels que statement_timeout, idle_in_transaction_statement_timeout et idle_session_timeout pour les versions 14 et ultérieures de PostgreSQL. Il est également recommandé de définir des délais d'expiration côté client et côté serveur, tels que tcp_keepalives_idle, tcp_keepalives_interval, tcp_keepalives_count.

Vous pouvez définir le paramètre statement_timeout aux niveaux appropriés, tels que l'instruction, le niveau utilisateur, la base de données ou l'instance.

Remarque : Il n'est pas recommandé de définir un délai d'expiration court à un niveau d'instance ou de base de données, car cela annule les requêtes de longue durée intentionnelles. Si log_min_error_statement est défini sur ERROR ou une valeur inférieure, l'instruction dont le délai a expiré est journalisée. Pour plus d'informations, consultez la page Comportement des instructions sur le site Web de PostgreSQL.

Informations connexes

Comment puis-je vérifier les requêtes en cours et diagnostiquer les problèmes de consommation de ressources pour mon instance de base de données Amazon RDS for PostgreSQL ou Aurora PostgreSQL ?

Comment puis-je identifier et résoudre les problèmes de performance et de lenteur d’exécution des requêtes dans mon instance RDS for PostgreSQL ou Aurora compatible avec PostgreSQL ?