PostgreSQL : transactions, verrous et interblocages

Mama Ngo a acheté une seconde caisse. Samedi dernier, il ne restait qu'une bouteille d'huile végétale : « Une dame l'a payée chez Nadia pendant qu'un monsieur la payait chez moi. Deux tickets, une seule bouteille. La machine n'a pas vu qu'on vendait la même chose en même temps ? » Tant qu'il n'y avait qu'une caisse, les ventes passaient l'une après l'autre. Avec deux, elles se croisent. Cet atelier ouvre deux terminaux, un par caisse, et rejoue le samedi dans l'ordre exact où les deux caisses agissent. Vous voyez d'abord ce qu'une session voit du travail d'une autre, avant et après COMMIT, puis vous reproduisez la vente fantôme : aucune erreur, deux ventes validées, une bouteille. Vous rencontrez votre premier verrou, un terminal qui ne rend pas la main parce que l'autre caisse tient la ligne. Puis vous écrivez la vente qui ne peut pas survendre, en laissant la base compter, et vous voyez PostgreSQL relire la ligne après l'attente. Vous réservez une ligne avant de décider avec SELECT FOR UPDATE, vous travaillez dans un cliché figé en REPEATABLE READ jusqu'à l'erreur de sérialisation, et vous provoquez un interblocage que la base dénoue en sacrifiant l'une des deux caisses. Et une dernière scène : la transaction oubliée qui fige tout le monde. La retrouver et la couper, c'est le métier d'administrateur, et c'est le défi qui clôt le parcours.