PostgreSQL implementeert Serializable Snapshot Isolation (SSI) met gebruik van predikaatvergrendeling en serialisatiegrafiektesten om echte serialiseerbaarheid te bereiken zonder de prestatiekosten van traditionele tweefasenvergrendeling. De 40001 fout (serialization_failure) treedt specifiek op tijdens write skew of read-write conflicten waarbij twee transacties een rw-afhankelijkheidscyclus tot stand brengen. Bijvoorbeeld, Transactie A leest rijen die aan een predikaat voldoen (bijv. WHERE color = 'red'), Transactie B leest rijen die aan een niet-overlappend predikaat voldoen (bijv. WHERE color = 'blue'), vervolgens werkt A rijen bij naar 'blauw' terwijl B rijen bijwerkt naar 'rood'. Geen van beide transacties blokkeert de andere, maar het resultaat is niet-serialiseerbaar.
Dit patroon vertegenwoordigt een gevaarlijke structuur in de serialisatiegrafiek: twee opeenvolgende rw-antidependencies die een potentiële cyclus vormen. PostgreSQL detecteert dit en annuleert één transactie om abnormale toestanden te voorkomen. Het probleem is subtiel omdat de transacties mogelijk verschillende fysieke rijen wijzigen, waardoor het conflict onzichtbaar is voor de rijvergrendelingsmechanismen die in lagere isolatieniveaus worden gebruikt.
De vereiste oplossing vereist dat de applicatie een optimistische retry-lus implementeert. Bij het opvangen van SQL EXCEPTION '40001' moet de applicatie de huidige transactie terugdraaien en de gehele operatie opnieuw proberen met exponentiële vertraging. In tegenstelling tot deadlocks, die doorgaans worden opgelost door meteen opnieuw te proberen, profiteren serialisatiefouten bij hoge belasting van jittered vertragingen om te voorkomen dat er een denderende kudde ontstaat.
-- Voorbeeld van applicatie retry-logica in PL/pgSQL DO $$ DECLARE retries INT := 0; max_retries INT := 3; BEGIN WHILE retries < max_retries LOOP BEGIN SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL SERIALIZABLE; PERFORM * FROM inventory WHERE category = 'electronics' AND count > 0; UPDATE inventory SET count = count - 1 WHERE item_id = 123; COMMIT; EXIT; EXCEPTION WHEN SQLSTATE '40001' THEN ROLLBACK; retries := retries + 1; PERFORM pg_sleep(power(2, retries) * 0.1); -- Exponentiële backoff END; END LOOP; END $$;
Een platform voor het uitwisselen van concerttickets stond gebruikers toe om zitplaatsencategorieën te ruilen via check-then-act logica. Transactie A controleerde of VIP-plaatsen beschikbaar waren en degradeerde vervolgens een vastgehouden VIP-plaats naar Standaard. Tegelijkertijd controleerde Transactie B de beschikbaarheid van Standaard en verhoogde een Standaardplaats naar VIP. Onder READ COMMITTED lazen beide transacties de beschikbaarheid als waar, voerden updates uit en het systeem eindigde met negatieve voorraad in beide categorieën, ondanks dat elke transactie beperkingen controleerde.
Er werden drie oplossingen ontworpen. De eerste gebruikte expliciete SELECT FOR UPDATE vergrendeling, maar dit faalde toen beschikbaarheidquery's nul rijen retour gaven, geen vergrendelingen verwierf en het systeem kwetsbaar liet voor fantoominvoegen. De tweede benadering implementeerde ADVISORY LOCKS met gebruik van pg_try_advisory_lock() om toegang tot zitplaatsencategorieën te serialiseren, wat conflicten voorkwam maar complexe vergrendelingsrisico's introduceerde en de doorvoer met 40% verminderde door serialisatie van alle categoriecontroles.
De derde oplossing adoptieerde SERIALIZABLE isolatie met een applicatieniveau retry-lus. Dit werd gekozen omdat het juistheid garandeerde zonder handmatig vergrendelingsbeheer, en de retry-overhead acceptabel was gezien de lage frequentie van gelijktijdige ruilen ten opzichte van leesperiodes. De implementatie gebruikte een JDBC retry-handler die SQLException met SQLState 40001 opvangen, wachtte 100ms * 2^attempt, en de transactie opnieuw uitvoerde. Dit elimineerde overboekingsincidenten volledig, hoewel de p99-latentie met 15ms toenam tijdens piekverkopen.
Wat is het precieze verschil tussen predikaatvergrendelingen in Serializable isolatie en rijvergrendelingen in Repeatable Read?
Repeatable Read voorkomt niet-herhaalbare lezingen door rijen daadwerkelijk geretourneerd door een query te vergrendelen, maar het voorkomt geen fantoomlezingen — nieuwe rijen die door andere transacties zijn ingevoegd die aan de WHERE clausule van de query zouden voldoen. Serializable isolatie gebruikt predikaatvergrendelingen die het zoekbereik zelf vergrendelen, waardoor elke invoeging die overeenkomt met het query-predikaat wordt voorkomen, zelfs in rijen die niet bestonden toen de query werd uitgevoerd. Kandidaten verwarren vaak deze, in de veronderstelling dat Repeatable Read fantoomlezingen voorkomt of dat Serializable alleen bestaande rijen vergrendelt.
Hoe bepaalt het algoritme voor het testen van de serialisatiegrafiek welke transactie moet worden geannuleerd wanneer een cyclus wordt gedetecteerd?
PostgreSQL gebruikt een "eerste commit wint" strategie gecombineerd met gevaarlijke structuurdetectie. Wanneer een rw-conflict (read-write afhankelijkheid) ontstaat tussen gelijktijdige transacties, houdt het systeem bij of deze rand een cyclus in de serialisatiegrafiek voltooit. De transactie die de cyclus voltooit, wordt geannuleerd met SQLSTATE 40001. De keuze is deterministisch op basis van de grafiekstructuur in plaats van de leeftijd van de transactie, waarbij de abortie van transacties die het minste kostbare of laatst in de gedetecteerde cyclus zijn, de voorkeur heeft. Begrijpen dat dit een preventieve abortie is (het voorkomen van een ongeldige geschiedenis) in plaats van een deadlock (wachten op vergrendelingen) is essentieel voor een goede foutafhandeling.
Waarom kan SELECT FOR UPDATE falen om serialisatiefouten te voorkomen in scenario's waarin Serializable isolatie een conflict detecteert?
SELECT FOR UPDATE verwerft ROW SHARE vergrendelingen alleen op rijen die op het moment van uitvoering bestaan. In check-then-act patronen waarbij de initiële query nul rijen retourneert (bijv. controleren op nul beschikbare zitplaatsen), verwerft FOR UPDATE helemaal geen vergrendelingen, zodat een andere transactie de conflicterende rij kan invoegen. Serializable isolatie detecteert dit als een predikaatconflict omdat het "nul rijen" resultaat een geldige leesset vormt die is ongeldig gemaakt door de gelijktijdige invoeging. Kandidaten nemen vaak ten onrechte aan dat FOR UPDATE uitgebreide bescherming biedt, niet beseffend dat het geen verdediging biedt tegen fantoominvoegen wanneer het predikaat aanvankelijk niets overeenkomt.