PostgreSQL: transactions, locks and deadlocks

Mama Ngo has bought a second till. Last Saturday, there was only one bottle of vegetable oil left: "A lady paid for it at Nadia's till while a gentleman was paying for it at mine. Two receipts, one bottle. Didn't the machine see we were selling the same thing at the same time?" As long as there was only one till, sales went through one after the other. With two, they cross. This workshop opens two terminals, one per till, and replays the Saturday in the exact order in which the two tills act. You first see what one session sees of another's work, before and after COMMIT, then you reproduce the phantom sale: no error, two sales committed, one bottle. You meet your first lock, a terminal that does not give the prompt back because the other till holds the row. Then you write the sale that cannot oversell, by letting the database count, and you see PostgreSQL re-read the row after the wait. You reserve a row before deciding with SELECT FOR UPDATE, you work in a frozen snapshot in REPEATABLE READ until the serialisation error, and you trigger a deadlock that the database breaks by sacrificing one of the two tills. And one last scene: the forgotten transaction that freezes everyone. Finding it and cutting it off is the administrator's job, and it is the challenge that closes the path.