Så, vi har diskuterat frågor relaterade till isolering, och gjort en avstickare om dataorganisation på låg nivå. Och till sist har vi kommit till det mest intressanta – versionerna av rader.

Rubrik

Som vi redan har nämnt kan varje rad samtidigt förekomma i databasen i flera versioner. En version måste särskiljas från en annan. För detta ändamål har varje version två märkningar som definierar "tiden" för denna versions giltighet (xmin och xmax). I citat – eftersom det inte används tid i egentlig mening, utan en speciell växande räknare. Och denna räknare är transaktionsnumret.

(Som vanligt är det i verkligheten allt mer komplicerat: transaktionsnumret kan inte hela tiden öka på grund av den begränsade datalängden för räknaren. Men dessa detaljer kommer vi att titta närmare på när vi kommer till frysningsaspekten.)

När en rad skapas sätts värdet för xmin till transaktionsnumret som utförde INSERT-kommandot, medan xmax inte fylls i.

När en rad tas bort märks värdet för xmax i den aktuella versionen med transaktionsnumret som utförde DELETE.

När en rad ändras med UPDATE-kommandot utförs faktiskt två operationer: DELETE och INSERT. I den aktuella versionen av raden sätts xmax till transaktionsnumret som utförde UPDATE. Sedan skapas en ny version av samma rad; värdet för xmin överensstämmer med värdet för xmax i den föregående versionen.

Fälten xmin och xmax ingår i radens versionshuvud. Förutom dessa fält innehåller huvudet även andra, till exempel:

• infomask – en rad bitar som definierar egenskaperna för denna version. Det finns ganska många av dem; de viktigaste kommer vi att gå igenom steg för steg.
• ctid – en referens till nästa, nyare version av samma rad. I den senaste, aktuella versionen pekar ctid på just denna version. Numret har formatet (x,y), där x är sidnumret och y är ordningsnumret för pekaren i arrayen.
• en bitmask för osäkra värden – markerar de kolumner i denna version som innehåller ett osäkert värde (NULL). NULL är inte ett av de vanliga värdena för datatyperna, så denna indikator måste lagras separat.

Som ett resultat blir huvudet ganska stort – minst 23 byte per radversion, och oftast mer på grund av NULL-bitmasken. Om tabellen är "smal" (det vill säga innehåller få kolumner) kan overheadkostnaderna vara större än nyttoinformationen.

Infoga

Låt oss titta närmare på hur operationer med strängar utförs på låg nivå och börja med infogningen.

För experimentet skapar vi en ny tabell med två kolumner och ett index på en av dem:

=> SKAPA TABELL t(
  id serial,
  s text
);
=> SKAPA INDEX PÅ t(s);

Vi infogar en rad, först börjar vi med en transaktion.

=> BÖRJA;
=> INFOGA IN I t(s) VÄRDEN ('FOO');

Här är numret på vår nuvarande transaktion:

=> VÄLJ txid_current();

 txid_current 
--------------
         3664
(1 rad)

Låt oss titta på innehållet på sidan. Funktionen heap_page_items från tillägget pageinspect gör det möjligt att få information om pekare och versioner av rader:

=> VÄLJ * FRÅN heap_page_items(get_raw_page('t',0)) gx

-[ POST 1 ]-------------------
lp          | 1
lp_off      | 8160
lp_flags    | 1
lp_len      | 32
t_xmin      | 3664
t_xmax      | 0
t_field3    | 0
t_ctid      | (0,1)
t_infomask2 | 2
t_infomask  | 2050
t_hoff      | 24
t_bits      | 
t_oid       | 
t_data      | x0100000009464f4f

Notera att ordet heap (hög) i PostgreSQL avser tabeller. Detta är ytterligare en underlig användning av termen — en hög är en känd datastruktur, som inte har något gemensamt med en tabell. Här används ordet i betydelsen 'allt är hopblandat', till skillnad från ordnade index.

Funktionen visar data "som de är", i ett format som är svårt att förstå. För att reda ut detta kommer vi att lämna kvar endast en del av informationen och avkoda den:

=> VÄLJ '(0,'||lp||')' SOM ctid,
       FALL lp_flags
         NÄR 0 DÅ 'används ej'
         NÄR 1 DÅ 'normal'
         NÄR 2 DÅ 'omdirigera till '||lp_off
         NÄR 3 DÅ 'död'
       SLUT SOM tillstånd,
       t_xmin som xmin,
       t_xmax som xmax,
       (t_infomask & 256) > 0  SOM xmin_commited,
       (t_infomask & 512) > 0  SOM xmin_aborted,
       (t_infomask & 1024) > 0 SOM xmax_commited,
       (t_infomask & 2048) > 0 SOM xmax_aborted,
       t_ctid
FRÅN heap_page_items(get_raw_page('t',0)) gx

-[ POST 1 ]-+-------
ctid          | (0,1)
tillstånd     | normal
xmin          | 3664
xmax          | 0
xmin_commited | f
xmin_aborted  | f
xmax_commited | f
xmax_aborted  | t
t_ctid        | (0,1)

Det här är vad vi har gjort:

• Vi lade till en nolla till pekarens nummer för att få det i samma form som t_ctid: (sidanummer, pekarnummer).
• Vi avkodade tillståndet för pekaren lp_flags. Här är det "normal" – vilket betyder att pekaren verkligen pekar på en version av raden. Andra värden kommer vi att titta på senare.
• Av alla informationsbitar har vi just nu bara extraherat två par. Bitarna xmin_committed och xmin_aborted visar om transaktionen med nummer xmin har bekräftats (eller avbrutits). Två motsvarande bitar avser transaktionen med nummer xmax.

Vad ser vi? När en rad infogas på en tabellsida kommer en pekare med nummer 1 att visas, som refererar till den första och enda versionen av raden.

I raden version är fältet xmin ifyllt med numret för den aktuella transaktionen. Transaktionen är fortfarande aktiv, så båda bitarna xmin_committed och xmin_aborted är inte inställda.

Fältet ctid i raden version refererar till samma rad. Det betyder att en nyare version inte finns.

Fältet xmax är fyllt med det fiktiva numret 0, eftersom denna version av raden inte har tagits bort och är aktuell. Transaktioner kommer inte att ta hänsyn till detta nummer eftersom biten xmax_aborted är inställd.

Låt oss ta ett steg till för att förbättra läsbarheten genom att lägga till informationsbitar till transaktionsnumren. Vi skapar en funktion eftersom vi kommer att behöva den här frågan mer än en gång:

=> CREATE FUNCTION heap_page(relname text, pageno integer)
RETURNS TABLE(ctid tid, state text, xmin text, xmax text, t_ctid tid)
AS $$
SELECT (pageno,lp)::text::tid AS ctid,
       CASE lp_flags
         WHEN 0 THEN 'unused'
         WHEN 1 THEN 'normal'
         WHEN 2 THEN 'redirect to '||lp_off
         WHEN 3 THEN 'dead'
       END AS state,
       t_xmin || CASE
         WHEN (t_infomask & 256) > 0 THEN ' (c)'
         WHEN (t_infomask & 512) > 0 THEN ' (a)'
         ELSE ''
       END AS xmin,
       t_xmax || CASE
         WHEN (t_infomask & 1024) > 0 THEN ' (c)'
         WHEN (t_infomask & 2048) > 0 THEN ' (a)'
         ELSE ''
       END AS xmax,
       t_ctid
FROM heap_page_items(get_raw_page(relname,pageno))
ORDER BY lp;
$$ LANGUAGE SQL;

I detta format blir det betydligt tydligare vad som händer i rubriken för raden version:

=> SELECT * FROM heap_page('t',0);

 ctid  | state  | xmin | xmax  | t_ctid 
-------+--------+------+-------+--------
 (0,1) | normal | 3664 | 0 (a) | (0,1)
(1 row)

Liknande, men betydligt mindre detaljerad information kan också erhållas direkt från tabellen, genom att använda pseudokolumnerna xmin och xmax:

=> SELECT xmin, xmax, * FROM t;

 xmin | xmax | id |  s  
------+------+----+-----
 3664 |    0 |  1 | FOO
(1 row)

Commit

Vid en lyckad transaktion måste statusen komma ihåg — markera att den har blivit bekräftad. Detta sker med en struktur som kallas XACT (och fram till version 10 kallades den CLOG (commit log) och detta namn kan fortfarande förekomma på olika ställen).

XACT — är ingen systemkatalogtabell; det är filer i katalogen PGDATA/pg_xact. För varje transaktion tilldelas två bitar: committed och aborted — precis som i rubriken för raden version. Denna information är uppdelad över flera filer enbart för bekvämlighetens skull, vi återkommer till denna fråga när vi diskuterar fryst data. Arbetet med dessa filer sker sidovis, precis som med alla andra.

Så, vid registrering av transaktionen i XACT sätts biten committed för denna transaktion. Och det är allt som händer vid registreringen (även om vi än så länge inte pratar om förinspelningens logg).

När någon annan transaktion refererar till tabellens sida som vi just har tittat på, måste den besvara några frågor.

1. Har transaktionen xmin avslutats? Om inte, ska den skapade versionen av raden inte vara synlig.
   En sådan kontroll görs genom att granska en annan struktur som ligger i den gemensamma minnet för instansen och kallas ProcArray. Här finns en lista över alla aktiva processer, och för varje anges numret på dess aktuella (aktiva) transaktion.
2. Om den har avslutats, hur – genom registrering eller avbokning? Om avbokning, ska versionen av raden inte heller vara synlig.
   Det är just därför som XACT behövs. Men, även om de senaste sidorna av XACT lagras i buffrar i det aktiva minnet, är det kostsamt att kontrollera XACT varje gång. Därför skrivs den fastställda statusen för transaktionen en gång för alla i bitarna xmin_committed och xmin_aborted för versionen av raden. Om någon av dessa bitar är inställd, anses statusen för transaktionen xmin vara känd, och nästa transaktion behöver inte längre referera till XACT.

Varför sätts inte dessa bitar av själva transaktionen som utför insättningen? När insättningen sker vet transaktionen ännu inte om den kommer att avslutas framgångsrikt. Och vid registreringen är det redan oklart vilka specifika rader som har ändrats på vilka specifika sidor. Det kan vara många sådana sidor, och att minnas dem är inte fördelaktigt. Dessutom kan delar av sidorna ha spolas ut från buffertcache till disk; att läsa dem igen för att ändra bitarna skulle avsevärt sakta ner registreringen.

Den baksidan av besparingen är att efter ändringarna kan vilken transaktion som helst (även en som endast utför enkel läsning – SELECT) börja ändra databasens sidor i buffertcachen.

Så, låt oss registrera förändringen.

=> COMMIT;

Inga ändringar har gjorts i sidan (men vi vet att statusen för transaktionen redan har registrerats i XACT):

=> SELECT * FROM heap_page('t',0);

 ctid  | state  | xmin | xmax  | t_ctid 
-------+--------+------+-------+--------
 (0,1) | normal | 3664 | 0 (a) | (0,1)
(1 row)

Nu måste transaktionen, som först refererade till sidan, fastställa statusen för transaktionen xmin och registrera den i informationsbitarna:

=> SELECT * FROM t;

 id |  s  
----+-----
  1 | FOO
(1 rad)

=> SELECT * FROM heap_page('t',0);

 ctid  | state  |   xmin   | xmax  | t_ctid 
-------+--------+----------+-------+--------
 (0,1) | normal | 3664 (c) | 0 (a) | (0,1)
(1 rad)

Ta bort

Vid borttagning av en rad i fältet xmax för den aktuella versionen registreras numret för den aktuella borttagande transaktionen, och biten xmax_aborted återställs.

Låt oss notera att det fastställda värdet xmax, som motsvarar den aktiva transaktionen, fungerar som en radlåsning. Om en annan transaktion försöker uppdatera eller ta bort denna rad, kommer den att tvingas vänta på att transaktionen xmax ska avslutas. Mer om låsningar kommer vi att diskutera senare. Samtidigt noterar vi bara att antalet radlåsningar inte är begränsat. De tar ingen plats i RAM-minnet och systemets prestanda påverkas inte av deras antal. Visserligen har 'långa' transaktioner andra nackdelar, men det kommer vi också att ta upp senare.

Vi tar bort raden.

=> BEGIN;
=> DELETE FROM t;
=> SELECT txid_current();

 txid_current 
--------------
         3665
(1 row)

Vi ser att transaktionsnumret har registrerats i fältet xmax, men informationsbitarna är inte inställda:

=> SELECT * FROM heap_page('t',0);

 ctid  | state  |   xmin   | xmax | t_ctid 
-------+--------+----------+------+--------
 (0,1) | normal | 3664 (c) | 3665 | (0,1)
(1 row)

Återkallande

Återkallande av ändringar fungerar på samma sätt som bekräftelse, men i XACT sätts en bit för transaktionen till aborted. Återkallandet utförs lika snabbt som en bekräftelse. Även om kommandot heter ROLLBACK, sker ingen ångring av ändringar: allt som transaktionen har lyckats ändra i databladen förblir oförändrat.

=> ROLLBACK;
=> SELECT * FROM heap_page('t',0);

 ctid  | state  |   xmin   | xmax | t_ctid 
-------+--------+----------+------+--------
 (0,1) | normal | 3664 (c) | 3665 | (0,1)
(1 row)

Vid åtkomst av sidan kommer statusen att kontrolleras och biten för hint xmax_aborted kommer att ställas in i versionen av raden. Själva numret xmax förblir på sidan, men ingen kommer att titta på det längre.

=> SELECT * FROM t;

 id |  s  
----+-----
  1 | FOO
(1 rad)

=> SELECT * FROM heap_page('t',0);

 ctid  | state  |   xmin   |   xmax   | t_ctid 
-------+--------+----------+----------+--------
 (0,1) | normal | 3664 (c) | 3665 (a) | (0,1)
(1 row)

Uppdatering

Uppdatering fungerar så, som om den nuvarande versionen av raden först tog bort den gamla raden och sedan införde en ny.

=> BEGIN;
=> UPDATE t SET s = 'BAR';
=> SELECT txid_current();

 txid_current 
--------------
         3666
(1 row)

Frågan returnerar en rad (den nya versionen):

=> SELECT * FROM t;

 id |  s  
----+-----
  1 | BAR
(1 row)

Men på sidan ser vi båda versionerna:

=> SELECT * FROM heap_page('t',0);

 ctid  | state  |   xmin   | xmax  | t_ctid 
-------+--------+----------+-------+--------
 (0,1) | normal | 3664 (c) | 3666  | (0,2)
 (0,2) | normal | 3666     | 0 (a) | (0,2)
(2 rows)

Den borttagna versionen är märkt med numret för den aktuella transaktionen i fältet xmax. Dessutom är detta värde skrivet över det gamla, eftersom den föregående transaktionen har avbrutits. Och biten xmax_aborted är återställd eftersom statusen för den aktuella transaktionen fortfarande är okänd.

Den första versionen av raden refererar nu till den andra (fältet t_ctid), som till den mer aktuella.

På indexsidan visas en andra pekare och en andra rad som hänvisar till den andra versionen på tabellsidan.

Som vid borttagning tjänar värdet xmax i den första versionen av raden som tecken på att raden är låst.

Och vi avslutar transaktionen.

=> COMMIT;

Index

Än så länge har vi bara pratat om tabellsidor. Vad händer inuti indexen?

Informationen på indexsidor beror starkt på den specifika typen av index. Även inom en och samma typ av index kan det finnas olika typer av sidor. Till exempel har B-trädet en sida med metadata och "vanliga" sidor.

Vanligtvis innehåller sidan dock en array av pekare till rader och själva raderna (precis som på tabellsidan). Dessutom avsätts utrymme i slutet av sidan för specialdata.

Raderna i index kan också ha mycket olika strukturer beroende på typen av index. Till exempel innehåller rader som hör till bladsidor i B-trädet värdet av indexnyckeln och en referens (ctid) till den motsvarande raden i tabellen. I allmänhet kan ett index vara helt annorlunda uppbyggt.

Den viktigaste punkten är att det i index av något slag inte finns några versioner av rader. Eller man kan säga att varje rad representeras av exakt en version. Med andra ord finns det inga fält xmax och xmin i rubriken för indexraden. Man kan anta att pekarna från indexet pekar på alla tabellversioner av raderna — så att reda ut vilken version en transaktion kommer att se kan man endast göra genom att titta i tabellen. (Som vanligt är detta inte hela sanningen. I vissa fall möjliggör synkartan optimering av processen, men vi kommer att titta närmare på det senare.)

Därmed upptäcker vi pekare på båda versionerna på indexsidan, både den aktuella och den gamla:

=> SELECT itemoffset, ctid FROM bt_page_items('t_s_idx',1);

 itemoffset | ctid  
------------+-------
          1 | (0,2)
          2 | (0,1)
(2 rader)

Virtuella transaktioner

I praktiken använder PostgreSQL en optimering som gör att man kan "spara" transaktionsnummer.

Om en transaktion bara läser data påverkar den inte synbarheten av versioner av rader. Därför tilldelar den hanterande processen först en virtuell nummer (virtual xid) till transaktionen. Numret består av processens identifierare och ett sekventiellt tal.

Utdelning av detta nummer kräver ingen synkronisering mellan alla processer och utförs därför mycket snabbt. En annan anledning till att använda virtuella nummer kommer vi att bekanta oss med när vi pratar om frysningsprocessen.

Virtuella nummer beaktas inte i databilder.

Vid olika tidpunkter i systemet kan det finnas virtuella transaktioner med nummer som redan har använts, och det är normalt. Men ett sådant nummer kan inte skrivas in i databilder, eftersom det vid nästa tillgång till sidan kan tappa all mening.

=> BÖRJA;
=> VÄLJ txid_current_if_assigned();

 txid_current_if_assigned 
--------------------------
                         
(1 rad)

Om transaktionen börjar förändra data tilldelas den ett verkligt, unikt transaktionsnummer.

=> UPPDATERA konton STÄLL IN belopp = belopp - 1.00;
=> VÄLJ txid_current_if_assigned();

 txid_current_if_assigned 
--------------------------
                     3667
(1 rad)

=> COMMIT;

Nästa transaktioner

Säkerhetspunkter

I SQL definieras säkerhetspunkter (savepoint), som gör det möjligt att återkalla en del av transaktionsoperationerna utan att avbryta hela. Men detta passar inte in i det ovan nämnda schemat, eftersom statusen för transaktionen är en för alla dess förändringar, och inga data ångras fysiskt.

För att implementera en sådan funktionalitet delas en transaktion med en säkerhetspunkt upp i flera separata nästa transaktioner (subtransaction), vars status kan hanteras separat.

Nästa transaktioner har sitt eget nummer (större än numret för huvudtransaktionen). Statusen för nästa transaktioner sparas på vanligt sätt i XACT, men det slutgiltiga läget beror på statusen för huvudtransaktionen: om den avbryts avbryts även alla nästa transaktioner.

Information om nästlade transaktioner lagras i filer i katalogen PGDATA/pg_subtrans. Åtkomst till filerna sker via buffrar i den gemensamma minnet av instansen, organiserade på samma sätt som buffrarna i XACT.

Blanda inte ihop nästlade transaktioner och autonoma transaktioner. Autonoma transaktioner är helt oberoende av varandra, medan nästlade är beroende. Det finns inga autonoma transaktioner i vanlig PostgreSQL, och det är nog för det bästa: de behövs sällan och deras förekomst i andra databashanteringssystem ger ofta upphov till missbruk som alla lider av senare.

Låt oss rensa tabellen, börja transaktionen och sätta in en rad:

=> TRUNCATE TABLE t;
=> BEGIN;
=> INSERT INTO t(s) VALUES ('FOO');
=> SELECT txid_current();

 txid_current 
--------------
         3669
(1 rad)

=> SELECT xmin, xmax, * FROM t;

 xmin | xmax | id |  s  
------+------+----+-----
 3669 |    0 |  2 | FOO
(1 rad)

=> SELECT * FROM heap_page('t',0);

 ctid  | state  | xmin | xmax  | t_ctid 
-------+--------+------+-------+--------
 (0,1) | normal | 3669 | 0 (a) | (0,1)
(1 rad)

Nu sätter vi en sparpunkt och lägger till ytterligare en rad.

=> SAVEPOINT sp;
=> INSERT INTO t(s) VALUES ('XYZ');
=> SELECT txid_current();

 txid_current 
--------------
         3669
(1 rad)

Observera att funktionen txid_current() ger huvudtransaktionens nummer, inte den inre transaktionen.

=> SELECT xmin, xmax, * FROM t;

 xmin | xmax | id |  s  
------+------+----+-----
 3669 |    0 |  2 | FOO
 3670 |    0 |  3 | XYZ
(2 rad)

=> SELECT * FROM heap_page('t',0);

 ctid  | state  | xmin | xmax  | t_ctid 
-------+--------+------+-------+--------
 (0,1) | normal | 3669 | 0 (a) | (0,1)
 (0,2) | normal | 3670 | 0 (a) | (0,2)
(2 rad)

Låt oss återgå till sparpunkten och lägga till den tredje raden.

=> ROLLBACK TO sp;
=> INSERT INTO t(s) VALUES ('BAR');
=> SELECT xmin, xmax, * FROM t;

 xmin | xmax | id |  s  
------+------+----+-----
 3669 |    0 |  2 | FOO
 3671 |    0 |  4 | BAR
(2 rad)

=> SELECT * FROM heap_page('t',0);

 ctid  | state  |   xmin   | xmax  | t_ctid 
-------+--------+----------+-------+--------
 (0,1) | normal | 3669     | 0 (a) | (0,1)
 (0,2) | normal | 3670 (a) | 0 (a) | (0,2)
 (0,3) | normal | 3671     | 0 (a) | (0,3)
(3 rad)

På sidan ser vi fortfarande raden som lagts till av den avbrutna inre transaktionen.

Spara ändringarna.

=> COMMIT;
=> SELECT xmin, xmax, * FROM t;

 xmin | xmax | id |  s  
------+------+----+-----
 3669 |    0 |  2 | FOO
 3671 |    0 |  4 | BAR
(2 rad)

=> SELECT * FROM heap_page('t',0);

 ctid  | state  |   xmin   | xmax  | t_ctid 
-------+--------+----------+-------+--------
 (0,1) | normal | 3669 (c) | 0 (a) | (0,1)
 (0,2) | normal | 3670 (a) | 0 (a) | (0,2)
 (0,3) | normal | 3671 (c) | 0 (a) | (0,3)
(3 rad)

Nu är det tydligt att varje inre transaktion har sin egen status.

Observera att inre transaktioner inte kan användas uttryckligen i SQL, det vill säga att man inte kan starta en ny transaktion utan att avsluta den aktuella. Denna mekanism aktiveras implicit vid användning av sparpunkter, liksom vid hantering av undantag i PL/pgSQL och i andra mer exotiska fall.

=> BEGIN;

BEGIN

=> BEGIN;

VARNING:  det finns redan en pågående transaktion
BEGIN

=> COMMIT;

COMMIT

=> COMMIT;

VARNING:  det finns ingen pågående transaktion
COMMIT

Fel och atomaritet i operationerna

Vad händer om ett fel inträffar under utförandet av en operation? Till exempel:

=> BEGIN;
=> SELECT * FROM t;

 id |  s  
----+-----
  2 | FOO
  4 | BAR
(2 rad)

=> UPDATE t SET s = repeat('X', 1/(id-4));

FEL:  division med noll

Ett fel har inträffat. Nu anses transaktionen vara avbruten och inga operationer är tillåtna i den:

=> SELECT * FROM t;

FEL:  aktuell transaktion är avbruten, kommandon ignoreras tills transaktionsblockets slut

Och även om man försöker spara ändringarna kommer PostgreSQL att meddela om avbrottet:

=> COMMIT;

ROLLBACK

Varför kan man inte fortsätta med en transaktion efter ett fel? Det beror på att felet kan ha inträffat på ett sätt så att vi skulle ha fått åtkomst till en del av ändringarna — atomariteten hos inte bara transaktionen utan även operatören skulle ha brutits. Som i vårt exempel där operatören hann uppdatera en rad innan felet inträffade:

=> SELECT * FROM heap_page('t',0);

 ctid  | state  |   xmin   | xmax  | t_ctid 
-------+--------+----------+-------+--------
 (0,1) | normal | 3669 (c) | 3672  | (0,4)
 (0,2) | normal | 3670 (a) | 0 (a) | (0,2)
 (0,3) | normal | 3671 (c) | 0 (a) | (0,3)
 (0,4) | normal | 3672     | 0 (a) | (0,4)
(4 rader)

Det ska nämnas att psql har ett läge som faktiskt tillåter att transaktionen fortsätter efter ett fel, som om de felaktiga operationerna rullas tillbaka.

=> set ON_ERROR_ROLLBACK on
=> BEGIN;
=> SELECT * FROM t;

 id |  s  
----+-----
  2 | FOO
  4 | BAR
(2 rad)

=> UPDATE t SET s = repeat('X', 1/(id-4));

FEL:  division med noll

=> SELECT * FROM t;

 id |  s  
----+-----
  2 | FOO
  4 | BAR
(2 rad)

=> COMMIT;

Det är lätt att förstå att psql i detta läge faktiskt sätter en oexplicit återställningspunkt före varje kommando, och vid ett fel initierar det en återställning till den. Detta läge används inte som standard, eftersom det medför betydande overheadkostnader att sätta återställningspunkter (även utan att rulla tillbaka till dem).

Fortsättning.

Källa: habr.com