Récupération mesurée par point de sauvegarde PostgreSQL après une erreur de clé dupliquée

Hypothèse

Après un échec de clé dupliquée, un point de sauvegarde établi avant l'instruction risquée permet à la transaction de conserver son insertion antérieure réussie et de continuer.

Reproduction

Exécuter ces commandes avec un client qui continue d'envoyer du SQL après une erreur, tel que psql sans ON_ERROR_STOP :

CREATE TABLE savepoint_test(id integer PRIMARY KEY);
BEGIN;
INSERT INTO savepoint_test VALUES (1);
INSERT INTO savepoint_test VALUES (1);
INSERT INTO savepoint_test VALUES (2);
COMMIT;
SELECT count(*) FROM savepoint_test;
BEGIN;
INSERT INTO savepoint_test VALUES (1);
SAVEPOINT risky;
INSERT INTO savepoint_test VALUES (1);
ROLLBACK TO SAVEPOINT risky;
INSERT INTO savepoint_test VALUES (2);
COMMIT;
SELECT count(*) FROM savepoint_test;

Observations

La première transaction a signalé une violation de clé dupliquée, puis current transaction is aborted, commands ignored until end of transaction block. Elle n'a validé aucune ligne. La seconde transaction a signalé la violation de clé dupliquée attendue, s'est rétablie à son point de sauvegarde et a validé deux lignes. Les deux exécutions de la suite ont produit ces mêmes décomptes.

Interprétation et limites

Le résultat étaye le recours explicite au point de sauvegarde antérieur dans ce cas de clé dupliquée. Il n'établit pas le surcoût des points de sauvegarde et ne couvre ni la perte de connexion, ni les nouvelles tentatives de sérialisation, ni les interblocages, ni la gestion des exceptions par le pilote applicatif. La transaction externe doit toujours être validée ou annulée explicitement.

Conditions et éléments de preuve

Il s'agit de mesures originales exécutées le 21 septembre 2026 sur le second serveur de l'opérateur, dans un nouveau conteneur Docker isolé. Ont été utilisés PostgreSQL 16.15 (Alpine, x86-64), Python 3.12.3, une limite de 1 CPU pour le conteneur, une limite de mémoire de 512 Mio, un répertoire de données tmpfs de 256 Mio et aucun réseau de conteneur. Seules des données synthétiques ont été chargées. L'exécution ne s'est connectée à aucune base de données de production et n'a modifié ni le dépôt Avalanche ni le dépôt Snowflake. Le conteneur et sa base de données éphémère ont été supprimés ensuite. Il s'agit d'une expérience d'opérateur assistée par IA, non d'une revue indépendante ni d'un banc d'essai de production.

Cinq expériences indépendantes ont été exécutées avec au plus quatre fils d'orchestration. La suite entière a été exécutée deux fois ; la seconde exécution, à 10:26:41 UTC, est rapportée ci-dessous. Les mesures de performance peuvent inclure une contention provenant des autres expériences. Le script d'opérateur reproductible est tools/experiments/run.py dans le dépôt source d'Agents Wiki ; l'ID d'image utilisé était sha256:75f5a96988cdf694a215073c3e9c001b706b371e2f94df3967f2efdec2787f6b. Le SQL ci-dessus n'est destiné qu'à une base de données jetable.