Erreur PostgreSQL : current transaction is aborted

SQLSTATE 25P02 (in_failed_sql_transaction) · Mis à jour 9 juillet 2026

ERROR:  current transaction is aborted, commands ignored until end of transaction block

Cette erreur n'est jamais la cause racine. Une instruction antérieure dans la même transaction a déjà échoué, la transaction est entrée dans l'état annulé, et PostgreSQL rejette désormais toute commande ultérieure jusqu'à ce que vous mettiez fin à la transaction avec ROLLBACK. La question à laquelle répondre est toujours : quelle était la première erreur ?

Ce que signifie cette erreur

Dès qu'une instruction à l'intérieur d'une transaction échoue, PostgreSQL garantit que la transaction dans son ensemble ne peut pas valider — permettre à d'autres instructions de « réussir » vous laisserait valider une unité de travail à moitié appliquée. Il les refuse donc toutes, en répétant ce message, jusqu'à ce que l'application émette ROLLBACK (ou revienne à un savepoint pris avant l'échec).

Si vous voyez des flots de 25P02 dans vos journaux, lisez-les comme un symptôme à deux couches : une erreur d'origine (une ligne, facile à manquer) et une application qui a continué à utiliser la connexion comme si de rien n'était (le flot).

Causes fréquentes

• L'application avale la première exception — un try/catch qui journalise et continue, toujours à l'intérieur de la transaction, toujours sur la même connexion.
• Du code de framework ou de driver qui ne fait pas de rollback sur erreur avant de réutiliser la session.
• Un pool de connexions qui distribue une connexion bloquée dans une transaction en échec parce qu'il ne réinitialise pas l'état à la libération.
• Des scripts psql s'exécutant dans BEGIN ... COMMIT qui continuent après une erreur (par défaut psql poursuit).

Comment la diagnostiquer

• Dans le journal du serveur, regardez ce que la même session a fait juste avant le flot de 25P02 — avec %p (pid) dans log_line_prefix vous pouvez suivre la session ; la première ERROR de ce pid est votre vrai problème.
• Dans l'application, journalisez et inspectez la première exception, pas celles d'après : une association très courante est une violation de clé unique suivie d'un flot de 25P02 provenant de code qui l'a « gérée » et a poursuivi.
• De façon interactive dans psql, l'erreur d'origine est simplement celle affichée juste au-dessus.

Comment la corriger

• Sur toute erreur d'instruction, faites un rollback — puis réessayez toute la transaction si approprié. Structurez le code de sorte qu'une exception à l'intérieur d'une transaction ne puisse pas être attrapée sans mettre fin à la transaction.
• Échecs attendus → savepoints, afin qu'un échec n'empoisonne pas la transaction :

  BEGIN;
  SAVEPOINT attempt;
  INSERT INTO users ...;            -- peut échouer
  -- en cas d'erreur :
  ROLLBACK TO SAVEPOINT attempt;    -- la transaction reste utilisable
  COMMIT;

  Mieux encore, quand l'échec attendu est un doublon, utilisez ON CONFLICT et évitez l'erreur entièrement.
• Scripts : exécutez psql avec ON_ERROR_STOP (psql -v ON_ERROR_STOP=1) pour qu'une erreur arrête le script au lieu de cascader ; de façon interactive, \set ON_ERROR_ROLLBACK interactive fait entourer les instructions de savepoints par psql pour vous.
• Pools : assurez-vous que les connexions font un rollback / une réinitialisation (par ex. DISCARD ALL) au retour dans le pool.