Nii, oleme käsitlenud teemasid, mis on seotud isoleerimisega, ja teinud kõrvalepõike madala taseme andmete korraldamisse. Ja lõpuks jõudsime kõige huvitavamani — stringiversioonideni.

Pealkiri

Nagu me juba mainisime, võib iga string vestelda andmebaasis samal ajal mitmes versioonis. Üks versioon tuleb teisest kuidagi eristada. Selleks on igal versioonil kaks märget, mis määravad selle versiooni kehtivuse „aja“ (xmin ja xmax). Kutsume seda „ajaks”, kuna tegelikult ei kasutata aega sellisel kujul, vaid spetsiaalset kasvavat loendurit. Ja see loendur on transaktsiooni number.

(Nagu tavaliselt, on asi tegelikult keerulisem: transaktsioonide number ei saa pidevalt suureneda, kuna loenduri täpsus on piiratud. Kuid neid üksikasju käsitleme üksikasjalikult, kui jõuame külmutamise teemadeni.)

Kui string luuakse, siis xmin väärtus määratakse transaktsiooni numbriks, mis täitis INSERT käsu, ja xmax ei täidetud.

Kui string kustutatakse, siis praeguse versiooni xmax väärtus märgitakse kustutamise teinud transaktsiooni numbriga.

Kui stringi muudetakse UPDATE käsuga, siis tehakse tegelikult kaks operatsiooni: KUSTUTA ja SISSESEDA. Praeguse stringi versioonis määratakse xmax, mis võrdub transaktsiooni numbriga, mis täitis UPDATE. Seejärel luuakse sama stringi uus versioon; xmin väärtus sellel on sama, mis eelneva versiooni xmax.

Väli xmin ja xmax kuuluvad stringi versiooni pealkirja. Lisaks nendele väljadele sisaldab pealkiri ka teisi, näiteks:

• infomask — bitti rida, mis määratleb selle versiooni omadused. Nende arv on üsna suur; peamised neist käsitleme järk-järgult.
• ctid — viide järgmisele, uuemale versioonile sama stringi kohta. Kõige uuema, kehtiva stringi versioon viitab sellele versioonile. Nummer on kujul (x,y), kus x on lehe number, y on viite järjekorranumber massiivis.
• mitteteadlike väärtuste bitikaart — tähistab neid veerge, millel on selle versiooni puhul teadmata väärtus (NULL). NULL ei ole üks tavapärastest andmetüüpide väärtustest, seega tuleb tähistamine salvestada eraldi.

Seega on pealkiri üsna suur — vähemalt 23 baiti iga stringi versiooni kohta, ja tavaliselt rohkem NULL-i bitikaardi tõttu. Kui tabel on „kitsas” (st sisaldab vähe veerge), võivad halduskoormused olla suuremad kui kasulik teave.

Sisestamine

Vaatame lähemalt, kuidas madala taseme stringioperatsioonid toimuvad ja alustame sisestamisest.

Katsetamiseks loome uue tabeli, millel on kaks veergu ja indeks ühe neist:

=> LOOMA TABEL t(
  id seeria,
  s tekst
);
=> LOOMA INDEKS ON t(s);

Sisestame ühe rea, alustades eelnevalt tehingut.

=> ALUSTAMA;
=> SISSESTAMA t(s) VÄÄRTUS ('FOO');

Siin on meie praeguse tehingu nummer:

=> VALI txid_current();

 txid_current 
--------------
         3664
(1 rida)

Vaata saiti sisu. Laienduse pageinspect funktsioon heap_page_items võimaldab saada teavet ridade viidete ja versioonide kohta:

=> VALI * FROM heap_page_items(get_raw_page('t',0)) gx

-[ KANDID 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

Pange tähele, et PostgreSQL kasutab sõna heap (kupatus) tabelite tähistamiseks. See on veel üks kummaline kasutusviis — kupatus on tuttav andmestruktuur,, millel pole tabeliga midagi ühist. Siin kasutatakse seda sõna tähenduses "kõik on kuhjatud kuhja", erinevalt korrastatud indeksitest.

Funktsioon näitab andmeid "nii nagu nad on", formaadis, mis on raskesti mõistetav. Et lahti mõtestada, jääme vaid osa teabest ja tõlgime selle:

=> VALI '(0,'||lp||')' NIMEKS ctid,
       JUHUL lp_flags
         KUI 0 SIIS 'kasutamata'
         KUI 1 SIIS 'tavaline'
         KUI 2 SIIS 'suunata '||lp_off
         KUI 3 SIIS 'surmav'
       LÕPP NIMEKS olek,
       t_xmin kui xmin,
       t_xmax kui xmax,
       (t_infomask & 256) > 0  NIMETA xmin_commited,
       (t_infomask & 512) > 0  NIMETA xmin_aborted,
       (t_infomask & 1024) > 0 NIMETA xmax_commited,
       (t_infomask & 2048) > 0 NIMETA xmax_aborted,
       t_ctid
FROM heap_page_items(get_raw_page('t',0)) gx

-[ KANDID 1 ]-+-------
ctid          | (0,1)
olek         | tavaline
xmin          | 3664
xmax          | 0
xmin_commited | f
xmin_aborted  | f
xmax_commited | f
xmax_aborted  | t
t_ctid        | (0,1)

See on, mida me tegime:

• Lisatud viite numbrisse null, et see oleks samas vormis nagu t_ctid: (lehe number, viite number).
• Tõlgitud viite lp_flags olek. Siin on see 'tavaline' — see tähendab, et viide viitab tõeliselt rea versioonile. Teised väärtused vaatame hiljem.
• Kogu informatiivsete bittide hulgast eraldasime praegu ainult kaks paari. Bittide xmin_committed ja xmin_aborted näitavad, kas xmin numbriga tehing on kinnitatud (tühistatud). Kaks sarnast bitti kuuluvad xmax numbriga tehingule.

Mida me näeme? Kui rida tabelile lisatakse, kuvatakse viit nr 1, mis viitab reas olevale esimesele ja ainukesele versioonile.

Rea versioonis on väli xmin täidetud praeguse tehingu numbriga. Tehing on endiselt aktiivne, seega ei ole bits xmin_committed ega xmin_aborted seadistatud.

Rea versiooni ctid väli viitab samale reale. See tähendab, et uuemat versiooni ei eksisteeri.

Väli xmax on täidetud vale numbriga 0, kuna selle rea versioon ei ole kustutatud ja on aktiivne. Tehingud ei pööra sellele numbrile tähelepanu, kuna xaborted bit on seadistatud.

Liikume samm edasi, et parandada loetavust, lisades tehingu numbri juurde teavet. Ja loome funktsiooni, kuna see päring tuleb meil kasutada veel korduvalt:

=> 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 'kasutamata'
         WHEN 1 THEN 'tavaline'
         WHEN 2 THEN 'suunatud '||lp_off
         WHEN 3 THEN 'surnud'
       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;

Nüüd on palju selgem, mis toimub rea versiooni päises:

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

 ctid  | state  | xmin | xmax  | t_ctid 
-------+--------+------+-------+--------
 (0,1) | tavaline | 3664 | 0 (a) | (0,1)
(1 rida)

Sarnast, kuid oluliselt vähem detailset teavet on võimalik saada ka otse tabelist, kasutades pseudoveerge xmin ja xmax:

=> SELECT xmin, xmax, * FROM t;

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

Kinnitus

Tehingu eduka lõpuleviimise korral tuleb meeles pidada selle staatust — märkida, et see on kinnitatud. Selleks kasutatakse struktuuri, mida nimetatakse XACT (ja versioonis 10 oli see tuntud kui CLOG (commit log) ning seda nime võib endiselt leida mitmest kohast).

XACT — ei ole süsteemi katalooge; need on failid PGDATA/pg_xact kataloogis. Igale tehingule on eraldatud kaks bitti: committed ja aborted — täpselt nagu rea versiooni päises. See teave on jaotatud mitmesse faili, et see oleks mugavam, ja me tuleme selle küsimuse juurde tagasi, kui arutame külmutamist. Ja nende failidega töötamine toimub lehekaupa, nagu ka kõigi teistega.

Nii et, kui tehing on XACT-is fikseeritud, seatakse vastava tehingu jaoks bit committed. Ja see on kõik, mis fikseerimise käigus juhtub (kuigi me ei räägi veel ettekirjutuse päevikust).

Kui mõni teine tehing pöördub tabeli lehe poole, mida me just vaatasime, peab see vastama mitmele küsimusele.

1. Kas tehing on xmin lõppenud? Kui ei, ei peaks loodud rida olema nähtav.
   Selline kontroll toimub, vaadates teist struktuuri, mis asub instantsi jagatud mälus ja mida nimetatakse ProcArray'ks. See sisaldab kõigi aktiivsete protsesside loendit ja igaühe jaoks on märgitud tema praegune (aktiivne) tehing.
2. Kui lõppes, siis kuidas — fikseerimise või tühistamise teel? Kui tühistamise teel, siis ei peaks rida samuti nähtav olema.
   Just selle jaoks ongi XACT vajalik. Kuid kuigi viimased XACT lehed salvestatakse mälus, on iga kord XACTi kontrollimine kulukas. Seetõttu salvestatakse kord leidud tehingu staatus ridade versioonides bittides xmin_committed ja xmin_aborted. Kui mõni neist bittidest on seatud, peetakse xmin tehingu seisundit teadaolevaks ja järgmisel tehingul ei ole enam vaja pöörduda XACT'i poole.

Miks neid bitte ei sea tehing, mis sisestust teeb? Kui sisestamine toimub, ei tea tehing veel, kas see lõpeb edukalt. Ja fikseerimise hetkel ei ole selge, millised read ja millistes lehtedes on muutunud. Selliseid lehti võib olla palju ja nende meelespidamine ei ole kasulik. Lisaks võivad mõned lehed olla vahemälust kettale tõrjutud; nende uuesti lugemine, et muuta bitte, tähendaks fikseerimise märkimisväärset aeglustumist.

Kulu kokkuhoiu tõeliseks tagajärjeks on see, et muudatuste järel võib iga tehing (isegi kõige lihtsam lugemine — SELECT) alustada andmelehtede muutmist vahemälus.

Nii et fikseerime muudatuse.

=> COMMIT;

Lehes ei ole midagi muutunud (aga me teame, et tehingu seisund on juba XACT-i salvestatud):

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

 ctid  | state  | xmin | xmax  | t_ctid 
-------+--------+------+-------+--------
 (0,1) | tavaline | 3664 | 0 (a) | (0,1)
(1 rida)

Nüüd peab esmalt lehe poole pöördunud tehing määrama xmin tehingu staatuse ja salvestab selle informatiivsetesse bittidesse:

=> SELECT * FROM t;

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

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

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

Kustutamine

Kui rida xmax väljale eemaldatakse, salvestatakse praeguse eemaldava tehingu number ja bit xmax_aborted nullitakse.

Tähelepanu, et seadistatud väärtus xmax, mis vastab aktiivsele tehingule, toimib rida blokeerimisena. Kui teine tehing kavatseb seda rida uuendada või eemaldada, peab see ootama tehingu xmax lõppu. Rikkumiste kohta räägime hiljem. Seni märgime ainult, et ridade blokeeringute arv ei ole millegiga piiratud. Need ei hõivata mälu ja süsteemi jõudlus ei kannata nende arvu tõttu. Tõsi, „pika” tehingu puhul on muid puudusi, kuid sellest räägime ka hiljem.

Eemaldame rea.

=> ALGUS;
=> KUSTUTA t;
=> VALI txid_current();

 txid_current 
--------------
         3665
(1 rida)

Näeme, et tehingu number on salvestatud xmax välja, kuid teabitsad ei ole seadistatud:

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

 ctid  | olek  |   xmin   | xmax | t_ctid 
-------+--------+----------+------+--------
 (0,1) | normaalne | 3664 (c) | 3665 | (0,1)
(1 rida)

Tühistamine

Muudatuste tühistamine töötab sarnaselt fikseerimisega, ainult et XACT-is seadistatakse tehingule bit aborted. Tühistamine toimub sama kiiresti kui fikseerimine. Kuigi käsk nimetatakse ROLLBACK, ei toimu muudatuste tagasivõtmist: kõik, mida tehing jõudis andmelehtedes muuta, jääb muutumatuks.

=> ROLLBACK;
=> VALI * HEAP_PAGE('t',0);

 ctid  | olek  |   xmin   | xmax | t_ctid 
-------+--------+----------+------+--------
 (0,1) | normaalne | 3664 (c) | 3665 | (0,1)
(1 rida)

Lehe juurde pöördumisel kontrollitakse olekut ja rida versioonis seadistatakse bit märgistus xmax_aborted. Xmax number jääb lehele, kuid keegi ei vaata seda enam.

=> SELECT * FROM t;

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

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

 ctid  | olek  |   xmin   |   xmax   | t_ctid 
-------+--------+----------+----------+--------
 (0,1) | normaalne | 3664 (c) | 3665 (a) | (0,1)
(1 rida)

Upgrade

Uuendamine töötab nii, et esmalt näivad olevat eemaldatud praeguse versiooni rida ja seejärel sisestatud uus.

=> ALGUS;
=> Uuenda t SET s = 'BAR';
=> VALI txid_current();

 txid_current 
--------------
         3666
(1 rida)

Küsi annab ühe reani (uue versiooni):

=> SELECT * FROM t;

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

Kuid lehel näeme kahte versiooni:

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

 ctid  | olek  |   xmin   | xmax  | t_ctid 
-------+--------+----------+-------+--------
 (0,1) | normaalne | 3664 (c) | 3666  | (0,2)
 (0,2) | normaalne | 3666     | 0 (a) | (0,2)
(2 rida)

Eemaldatud versioon on märgitud praeguse tehingu numbri abil xmax väljale. Lisaks on see väärtus salvestatud vana peale, kuna eelmine tehing tühistati. Ja bit xmax_aborted nullitati, kuna praeguse tehingu olek on veel teadmata.

Esimene versioon rida viitab nüüd teisele (väljavälja t_ctid), kui uuele.

Indeksilehel kuvatakse teine viit ja teine rida, mis osutab teisele versioonile tabelilehel.

Nagu ka kustutamisel, toimib rida maksimaalne väärtus xmax esimeses versioonis märkina, et rida on lukustatud.

Ja lõpetame tehingu.

=> COMMIT;

Indeksid

Kuni nüüd oleme rääkinud ainult tabelilehtedest. Mis aga juhtub indeksites?

Teave indeksilehtede kohta sõltub tugevasti konkreetse indeksi tüübist. Isegi ühe indeksi tüübi puhul võivad olla erinevad lehtede liigid. Näiteks B-puul on metaandmete leht ja 'tavalised' lehed.

Sellegipoolest sisaldab leht tavaliselt massiivi viiteid ridadele ja neid ridasid (nagu ka tabelilehe puhul). Lisaks on lehe lõpus ruum spetsiaalsete andmete jaoks.

Indeksides võivad read samuti olla väga erineva struktuuriga, olenevalt indeksi tüübist. Näiteks B-puul sisaldavad lehtedele kuuluvad read indekseeritava võtme väärtust ja viidet (ctid) vastavale tabeli reale. Üldiselt võib indeks olla üles ehitatud täiesti teistsugusel viisil.

Oluline on see, et ükskõik millise tüübi indeksites ei ole rida versioone. Või võib öelda, et igat rida esindab täpselt üks versioon. Teisisõnu, indeksirea pealkirjas ei ole välju xmin ja xmax. Võib öelda, et viidud indeksid viivad kõikide tabeliversioonide ridadeni — seega saab aru, millist versiooni tehing näeb, ainult tabelisse vaatates. (Nagu tavaliselt, see ei ole kogu tõde. Mõnel juhul võimaldab nähtavuse kaart protsessi optimeerida, kuid seda vaatame hiljem põhjalikult.)

Samas leidub indeksilehelt viiteid mõlemale versioonile, nii praegusele kui ka vanemale:

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

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

Virtuaalsed tehingud

Praktikas kasutab PostgreSQL optimeerimist, mis võimaldab 'säästa' tehingute numbreid.

Kui tehing ainult loeb andmeid, ei mõjuta see ridade versioonide nähtavust. Seetõttu annab teenindusprotsess alguses tehingule virtuaalse numbri (virtual xid). Number koosneb protsessi identifikaatorist ja järjestikulisest numbrist.

Selle numbri väljastamine ei nõua sünkroniseerimist kõigi protsesside vahel, mistõttu toimub see väga kiiresti. Teise põhjusena virtuaalsete numbrite kasutamiseks tutvume, kui räägime külmutamisest.

Virtuaalsed numbrid ei kajastu andmete hetkepiltides.

Erinevatel aegadel võivad süsteemis olla virtuaalsed tehingud numbritega, mida on juba kasutatud, ja see on normaalne. Kuid sellist numbrit ei tohi andmelehtedele kirjutada, sest järgmise kõne korral võib see kaotada igasuguse tähenduse.

=> ALGUS;
=> VALI txid_current_if_assigned();

 txid_current_if_assigned 
--------------------------
                         
(1 rida)

Kui tehing hakkab andmeid muutma, antakse talle tõeline, unikaalne tehingu number.

=> Uuenda kontod SET summa = summa - 1.00;
=> VALI txid_current_if_assigned();

 txid_current_if_assigned 
--------------------------
                     3667
(1 rida)

=> COMMIT;

Sisemised tehingud

Salvestuspunktid

SQL-is on määratletud salvestuspunktid (savepoint), mis võimaldavad tühistada osa tehingu toimingutest, katkestamata seda täielikult. Kuid see ei sobi ülaltoodud skeemiga, kuna tehingu olek on kõigi selle muudatuste jaoks ühine ja füüsiliselt ei tühistata mingeid andmeid.

Selle funktsiooni rakendamiseks jagatakse salvestuspunktiga tehing mitmeks eraldi sisemiseks tehinguks (subtransaction), mille staatust saab eraldi hallata.

Sisemistel tehingutel on oma number (suurem kui põhitehingu number). Sisemiste tehingute olekut salvestatakse tavalisel viisil XACT-is, kuid lõplik olek sõltub põhitehingu olekust: kui see tühistatakse, tühistatakse ka kõik sisemised tehingud.

Teave tehingute sisemuse kohta salvestatakse failides PGDATA/pg_subtrans katalooge. Failidele pääseb ligi eksemplari jagatud mälu puhversüsteemide kaudu, mis on organiseeritud samamoodi nagu XACT-i puhversüsteemid.

Ärge segage sisemisi tehinguid ja iseseisvaid tehinguid. Iseseisvad tehingud ei sõltu üksteisest, samas kui sisemised tehingud — sõltuvad. Ükski tavaline PostgreSQL ei sisaldanud iseseisvaid tehinguid ja see on tõenäoliselt parem: neid on tegelikult väga harva vaja ning nende olemasolu teistes andmebaasisüsteemides soodustab kuritarvitamist, mille tõttu kannatavad kõik hiljem.

Kustutame tabeli, alustame tehingut ja lisame rea:

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

 txid_current 
--------------
         3669
(1 row)

=> SELECT xmin, xmax, * FROM t;

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

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

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

Nüüd seadke salvestuspunkt ja lisage veel üks rida.

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

 txid_current 
--------------
         3669
(1 row)

Märka, et funktsioon txid_current() annab välja peamise, mitte pesastatud tehingu numbri.

=> SELECT xmin, xmax, * FROM t;

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

=> 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 rows)

Tagasi minnes salvestuspunktist ning lisades kolmanda rea.

=> 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 rows)

=> 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 rows)

Lehelt näeme jätkuvalt rida, mis lisati tühistatud pesastatud tehingu kaudu.

Fikseerime muudatused.

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

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

=> 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 rows)

Nüüd on hästi näha, et igal pesastatud tehingul on oma olek.

Märka, et pesastatud tehingute selgesõnaline kasutamine SQL-is ei ole lubatud, s.t. uut tehingut ei saa alustada, kui praegune pole lõpetatud. Seda mehhanismi rakendatakse kaudselt salvestuspunktide kasutamisel ning PL/pgSQL erandite töötlemise vältimisel ja mitmete muude, eksootilisemate juhtumite korral.

=> BEGIN;

BEGIN

=> BEGIN;

HOIATUS:  tehing on juba käimas
BEGIN

=> COMMIT;

COMMIT

=> COMMIT;

HOIATUS:  tehingut ei toimu
COMMIT

Vead ja operatsioonide atomicsus

Mis juhtub, kui operatsiooni käigus esineb viga? Näiteks nii:

=> BEGIN;
=> SELECT * FROM t;

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

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

ERROR:  jagamine nulliga

Viga. Nüüd loetakse tehing tühistatuks ja selles ei lubata ühtegi operatsiooni:

=> SELECT * FROM t;

ERROR:  praegune tehing on katkenud, käsud ignoreeritakse kuni tehingu ploki lõpuni

Ja isegi kui proovida muudatusi fikseerida, teatab PostgreSQL tühistamisest:

=> COMMIT;

ROLLBACK

Miks ei saa tehingut pärast viga jätkata? Asi on selles, et viga võis tekkida nii, et me oleksime saanud osa muudatustest — oleks rikutud isegi mitte tehingu, vaid operaatori aatomilisust. Nagu meie näites, kus operaator jõudis enne viga uuendada ühe rea:

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

 ctid  | olek  |   xmin   | xmax  | t_ctid 
-------+--------+----------+-------+--------
 (0,1) | normaalne | 3669 (c) | 3672  | (0,4)
 (0,2) | normaalne | 3670 (a) | 0 (a) | (0,2)
 (0,3) | normaalne | 3671 (c) | 0 (a) | (0,3)
 (0,4) | normaalne | 3672     | 0 (a) | (0,4)
(4 rida)

Tuleb märkida, et psql-il on režiim, mis siiski võimaldab jätkata tehingu töötamist pärast viga, nagu oleks vigane operaatori tegevus tagasi võetud.

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

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

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

ERROR:  jagamine nulliga

=> SELECT * FROM t;

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

=> COMMIT;

Pole raske arvata, et sellises režiimis seab psql tegelikult iga käsu ette mitteavaliku salvestuskoha ja juhul, kui toimub viga, algatab see tagasiviimise sinna. Sellist režiimi ei kasutata vaikimisi, kuna salvestuskohtade seadmine (isegi ilma nendele tagastamiseta) toob kaasa märkimisväärseid kulusid.

Jätkamine.

Allikas: habr.com