Les niveaux d'isolation Repeatable Read et Serializable peuvent produire des erreurs conçues pour empêcher des anomalies de sérialisation. Comme indiqué précédemment, les applications utilisant ces niveaux doivent être préparées pour tenter de nouveau les transactions qui échouent suite à des erreurs de sérialisation. Ce type de message d'erreur variera suivant les circonstances précises, mais il y aura toujours le code SQLSTATE 40001 (serialization_failure).

Il pourrait aussi être conseillé de reprendre les échecs de deadlock. Ils ont le code SQLSTATE 40P01 (deadlock_detected).

Dans certains cas, il est aussi approprié de tenter de nouveau après des échecs d'unicité, qui ont le code SQLSTATE 23505 (unique_violation), et des échecs de contrainte d'exclusion qui ont le code SQLSTATE 23P01 (exclusion_violation). Par exemple, si l'application sélectionne une nouvelle valeur pour une clé primaire après l'inspection les clés stockées enregistrées, elle pourrait obtenir un échec d'unicité parce qu'une autre application a sélectionné la même nouvelle clé en même temps. Ceci est en réalité un échec de sérialisation mais le serveur ne le détectera pas ainsi parce qu'il ne peut pas « voir » la connexion entre la valeur insérée et les lectures précédentes. Il existe aussi quelques cas spécifiques pour lesquels le serveur renverra une erreur d'unicité ou de contrainte d'exclusion même si, en principe, il a suffisamment d'informations pour déterminer qu'un problème de sérialisation en est la cause sous-jacente. Alors qu'il est recommendable de seulement tester de nouveau les erreurs serialization_failure de façon inconditionnelle, plus d'attention est nécessaire lors de nouvelles tentatives avec ces autres codes d'erreur car ils pourraient représenter des conditions d'erreur persistentes plutôt que des échecs temporaires.

Il est important de ré-essayer la transaction complète, incluant toute la logique qui décide quel SQL envoyer et/ou quelles valeurs utiliser. De ce fait, PostgreSQL n'offre pas une capacité de tentatives automatiques car il ne peut le faire sans garantie d'exactitude.

Une nouvelle tentative ne garantit pas que la transaction nouvellement essayée se termine ; plusieurs essais pourraient se révéler nécessaires. Dans les cas avec une contention très haute, il est possible que la fin d'une transaction demande de nombreuses tentatives. Dans les cas impliquant une transaction préparée en conflit, il pourrait être impossible de progresser jusqu'à ce que la transaction préparée soit validée ou annulée.