En utilisant AWS re:Post, vous acceptez les AWS re:Post Conditions d’utilisation

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

Lecture de 4 minute(s)
0

Je souhaite que les fonctions pg_cancel_backend (pid) et pg_terminate_backend (pid) mettent fin à un processus de longue durée dans mon Amazon Relational Database Service (Amazon RDS) for PostgreSQL ou l'instance de base de données Aurora PostgreSQL.

Brève description

PostgreSQL propose deux fonctions pour mettre fin aux requêtes :

  • pg_cancel_backend(pid) : Met fin à une requête mais maintient la connexion active.
  • pg_terminate_backend(pid) : Met fin à une requête et ferme la connexion. L'exécution de cette fonction met fin à la connexion complète et peut donc affecter les autres requêtes en cours d'exécution. À utiliser en dernier recours.

Pour utiliser ces 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 qui doit être annulée.

Remarques :

  • Le pid est l'ID du processus principal qui s'exécute pour annuler la requête. Utilisez la colonne pid de la vue pg_stat_activity pour trouver l'ID de processus 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 et pg_terminate_backend envoient des signaux (SIGINT ou SIGTERM respectivement) au processus de backend identifié par l'ID du processus. Pour plus d'informations, consultez la page Fonctions de signalisation du serveur sur le site Web de PostgreSQL.

Résolution

Consultez les exemples suivants pour les fonctions pg_cancel_backend(pid) et pg_terminate_backend(pid) :

Exemple : pg_cancel_backend(pid)

Lorsqu'elle est exécutée depuis une autre session, la commande suivante annule la requête exécutée depuis le backend de base de données avec pid 8121. Cette fonction renvoie la valeur vrai lorsque la requête est annulée correctement. Cette fonction renvoie la valeur faux si la requête n'existe plus ou si la connexion à la base de données n'existe pas.

postgres=> SELECT pg_cancel_backend(8121);
 pg_cancel_backend
------------------------
 t
(1 row)

Exemple : pg_terminate_backend(pid)

Lorsqu'elle est exécutée depuis une autre session, la commande suivante met fin à la connexion à la base de données avec pid 8121. Cette fonction renvoie la valeur vrai si le processus a réellement été 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. À la place, elle attend que le processus de backend se déroule correctement pendant CHECK_FOR_INTERRUPTS. Cela garantit qu'aucun processus n'est annulé, ce qui laisse la mémoire partagée dans un état incohérent

postgres=> SELECT pg_terminate_backend(8121);
 pg_terminate_backend
------------------------
 t
(1 row)

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

Parfois, les fonctions pg_cancel_backend( ) et pg_terminate_backend( ) n'annulent pas la requête. Cela est dû au fait que le processus de backend de la fonction s'exécute dans une section ininterrompue. Par exemple, le processus peut attendre d'acquérir un verrou léger ou un appel 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.

Redémarrez le moteur de base de données pour terminer le processus.

Quelques bonnes pratiques

  • Réglez les paramètres d’expiration de délai comme statement_timeout, idle_in_transaction_statement_timeout et idle_session_timeout (à partir de PostgreSQL version 14). Il est recommandé de définir également les délais d'expiration côté client et les délais d'expiration côté serveur (tcp_keepalives_idle, tcp_keepalives_interval, tcp_keepalives_count) de façon appropriée.
  • Le paramètre statement_timeout peut être défini aux niveaux appropriés (instruction, niveau utilisateur, base de données ou instance).
    Remarque : Il n'est pas recommandé de définir un délai d'expiration court au niveau de l'instance ou de la 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 enregistré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 les requêtes lentes dans mon instance RDS pour PostgreSQL ou Aurora PostgreSQL ?