Nii, oleme vaadanud küsimusi, mis on seotud isoleerimisega, ja tegime kõrvalepõike andmete korraldusest madalal tasemel. Ja lõpuks oleme jõudnud kõige huvitavama juurde — ridade versioonid.

Päis

Kuidas juba mainitud, võib iga rida samaaegselt olemas olla andmebaasis mitmes versioonis. Üksteisest tuleb versioonid millegipärast eristada. Selleks on igal versioonil olemas kaks märki, mis määravad selle versiooni „kehtivuse” aja (xmin ja xmax). Juttu on „ajast”, kuna tegelikult ei kasutata aega niivõrd, vaid erilist kasvavat arvestit. See arvesti on tehingu number.

(Nagu tavaliselt, on tegelikult kõik keerulisem: tehingu numbrid ei saa pidevalt suureneda piiratud bitisügavuse tõttu. Kuid need detailid käsitleme põhjalikult, kui jõuame külmutamise juurde.)

Kui rida luuakse, seadistatakse xmin väärtus tehingu numbriks, mis tegi INSERT käsu, samas kui xmax ei täideta.

Kui rida kustutatakse, märgistatakse praeguse versiooni xmax väärtus kustutamise teinud tehingu numbriga.

Kui rida muudetakse UPDATE käsuga, toimub tegelikult kaks toimingut: KUSTUTA ja INSERT. Rida seadistatakse praeguses versioonis xmax-iga, mis on tehingu number, mis teostas UPDATE. Seejärel luuakse sama rea uus versioon; sellel on xmin väärtus, mis vastab eelneva versiooni xmax-ile.

Väljad xmin ja xmax sisalduvad rea versiooni pealkirjas. Lisaks nendele väljadele sisaldab pealkiri ka teisi, näiteks:

• infomask — bitide rida, mis määratleb antud versiooni omadused. Neid on üsna palju; peamised neist vaatame järk-järgult üle.
• ctid — viidatud järgmise, uuema versiooni sama rea kohta. Kõige uuema, aktiivse, versiooni ctid viitab sellele samale versioonile. Number on kujul (x,y), kus x on lehe number ja y on viite järjestusnumber massiivis.
• määramatute väärtuste bitikaart — märgib need veerud antud versioonis, mis sisaldavad määramatut väärtust (NULL). NULL ei ole üks tavalisi andmetüüpe, seetõttu tuleb omadust hoida eraldi.

Seetõttu on pealkiri üsna suur — iga rea versiooni kohta vähemalt 23 bitti, tavaliselt rohkem tänu NULL-bitikaardile. Kui tabel on "kitsas" (st sisaldab väheseid veerge), võivad kulud ületada kasulikku teavet.

Sisestamine

Vaatame lähemalt, kuidas reaoperatsioonid madalamal tasemel toimuvad, ja alustame sisestamisest.

Eksperimentide jaoks loome uue tabeli, kus on kaks veergu ja indeks ühe neist järgi:

=> CREATE TABLE t(
  id serial,
  s text
);
=> CREATE INDEX ON t(s);

Sisestame ühe rea, alustades tehingut.

=> BEGIN;
=> INSERT INTO t(s) VALUES ('FOO');

Siin on meie praeguse tehingu number:

=> SELECT txid_current();

 txid_current 
--------------
         3664
(1 row)

Vaadakem lehe sisu. Funktsioon heap_page_items laiendamisest pageinspect võimaldab saada teavet näidikute ja ridade versioonide kohta:

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

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

Tähtis on märkida, et PostgreSQL'is tähistab sõna heap (virn) tabeleid. See on veel üks kummaline kasutusviis, kuna virn on tuntud andmestruktuur,, mis ei oma tabeliga midagi ühist. Siin kasutatakse seda sõna tähenduses «kõik on kuhjatud kokku», erinevalt järjestatud indeksitest.

Funktsioon näitab andmeid «nagu nad on», raskesti tajutavas formaadis. Selgusele jõudmiseks jätame alles vaid osa teabest ja dekodeerime selle:

=> SELECT '(0,'||lp||')' 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 as xmin,
       t_xmax as xmax,
       (t_infomask & 256) > 0  AS xmin_commited,
       (t_infomask & 512) > 0  AS xmin_aborted,
       (t_infomask & 1024) > 0 AS xmax_commited,
       (t_infomask & 2048) > 0 AS xmax_aborted,
       t_ctid
FROM heap_page_items(get_raw_page('t',0)) gx

-[ RECORD 1 ]-+-------
ctid          | (0,1)
state         | normal
xmin          | 3664
xmax          | 0
xmin_commited | f
xmin_aborted  | f
xmax_commited | f
xmax_aborted  | t
t_ctid        | (0,1)

Siin on, mida me tegime:

• Lisades osutaja numbrile nulli, et viia see samasugusele kujule nagu t_ctid: (lehe number, osutaja number).
• Oleme dešifreerinud lp_flags näitaja oleku. Siin on see 'normal' — see tähendab, et näitaja viitab tõepoolest rea versioonile. Teisi väärtusi arutame hiljem.
• Oleme seni esile tõstnud ainult kaks paari teavet. Bitid xmin_committed ja xmin_aborted näitavad, kas tehing numbriga xmin on kinnitatud (või tühistatud). Kaks sarnast bitti puudutavad tehingut numbriga xmax.

Mida me näeme? Kui rida sisestatakse tabeli lehele, tekib viit number 1, mis viitab reaalne esimesele ja ainule versioonile.

Rea versioonis on väli xmin täidetud praeguse tehingu numbriga. Tehing on endiselt aktiivne, seega mõlemad bitti xmin_committed ja xmin_aborted ei ole seatud.

Rea versiooni ctid viitab samale reale. See tähendab, et uut versiooni ei eksisteeri.

Väli xmax on täidetud vale numbri 0-ga, kuna see rea versioon ei ole kustutatud ja on aktuaalne. Tehingud ei pööra sellele numbrile tähelepanu, kuna bit xmax_aborted on seatud.

Teeme veel ühe sammu loetavuse parandamiseks, lisades tehingute numbrite juurde teavet. Loome funktsiooni, kuna see päring on meil veel mitmel korral vajalik:

=> LOOMI FUNKTSIOON 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 'normal'
         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;

Selline vorm on palju arusaadavam, mis juhtub rea versiooni päises:

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

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

Sarnase, kuid oluliselt vähem detailse, teabe saab ka otse tabelist, kasutades pseudokoldeid xmin ja xmax:

=> VALI xmin, xmax, * FROM t;

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

Fikseerimine

Kui tehing on edukalt lõpetatud, tuleb meeles pidada selle staatust — märkida, et see on fikseeritud. Selleks kasutatakse struktuuri, mida nimetatakse XACT (ja enne versiooni 10 nimetati seda CLOG (commit log), ja see nimetus võib endiselt ilmneda erinevates kohtades).

XACT — ei ole süsteemi katalooge sisaldav tabel; need on failid kataloogis PGDATA/pg_xact. Iga tehingu jaoks on seal eraldatud kaks bitti: committed ja aborted — just nagu ridade versioonide päises. See teave on jagatud mitmeks failiks puhtalt mugavuse huvides, me naaseme selle küsimuse juurde, kui käsitleme külmutamist. Ja nende failidega töötamine toimub lehekaupa, nagu ka kõikide teistega.

Nii et tehingu kinnitamise ajal XACT-is seatakse selle tehingu jaoks committed bitti. Ja see on kõik, mis kinnitamise ajal juhtub (kuigi me ei räägi veel logi eelregistreerimisest).

Kui mõni muu tehing pöördub tabelilehekülje poole, mida me just vaatasime, peab see vastama mitmele küsimusele.

1. Kas tehing xmin on lõppenud? Kui ei, siis loodud rida ei tohiks olla nähtav.
   Selline kontroll toimub veel ühe struktuuri vaatamise teel, mis asub instantsi jagatud mälus ja mida nimetatakse ProcArray. Seal on loetelu kõigist aktiivsetest protsessidest, ning igaühe jaoks on näidatud tema praeguse (aktiivse) tehingu number.
2. Kui see on lõppenud, siis kuidas — fikseerimise või tühistamise kaudu? Kui tühistamise kaudu, siis ei peaks versiooni rida ka nähtav olema.
   Just selleks ongi vajalik XACT. Kuigi XACTi viimased lehed säilitatakse mällu puhverdatult, on XACTi kontrollimine iga kord kulukas. Seetõttu salvestatakse kord juba tuvastatud tehingu olek bitidesse xmin_committed ja xmin_aborted versiooni reas. Kui üks neist bittidest on seatud, loetakse tehingu olek xmin teada olevaks ja järgmine tehing ei pea enam XACTi poole pöörduma.

Miks neid bitte ei seadista tehing, mis täidab sisestamise? Kui toimub sisestamine, ei tea tehing veel, kas see lõpetatakse edukalt. Ja fikseerimise hetkel ei ole selge, millised read millistes lehtedes on muudetud. Selliseid lehti võib olla palju ning nende meeles pidamine ei ole kasulik. Lisaks võivad osad lehed puhverdatud mälust kettale välja tõrjuda; nende uuesti lugemine, et bitte muuta, tähendaks fikseerimise oluliselt aeglustumist.

Kulu tõusmine seisneb selles, et pärast muudatusi võivad kõik tehingud (isegi lihtsa lugemise — SELECT korral) hakata muutma andmelehti vahemälus.

Kinnitame muudatuse.

=> COMMIT;

Lehel ei ole midagi muutunud (aga me teame, et tehingu staatus on juba salvestatud XACT-isse):

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

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

Nüüd peab tehing, mis esimesena lehele pöördus, määrama tehingu staatuse xmin ja salvestama selle teabelehtedes:

=> SELECT * FROM t;

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

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

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

Kustuta

Reakustutamisel salvestatakse praeguse kustutava tehingu number xmax aktiivse versiooni väljal, ning xmax_aborted bitti resettitakse.

Kuna xmax, mis vastab aktiivsele tehingule, toimib rea lukuna. Kui mõni teine tehing üritab seda rida uuendada või kustutada, peab ta ootama xmaxi tehingu lõpetamist. Lukkudest räägime hiljem. Praegu tuleb märkida, et rea lukustuste arv pole millegagi piiratud. Need ei võta ruumi mälus ja süsteemi jõudlus ei kannata nende arvu tõttu. Tõsi, "pikkadel" tehingutel on teised puudused, aga sellest räägime hiljem.

Kustutame rea.

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

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

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

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

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

Tühistamine

Muudatuste tühistamine töötab sarnaselt fikseerimisele, ainult et XACTis määratakse tehingule abort bit. Tühistamine toimub sama kiiresti kui fikseerimine. Kuigi käsk nimetatakse ROLLBACK, ei toimu muudatuste tagasivõtmist: kõik, mida tehing suutis andmelehtedele muuta, jääb muutumatuks.

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

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

Lehe kutsumise ajal kontrollitakse olekut, ja ridade versioonile seatakse abiteave xmax_aborted. Samas jääb xmax number lehele, kuid keegi ei vaata sellele enam.

=> SELECT * FROM t;

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

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

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

Uuendamine

Uuendamine töötab nii, nagu oleks alguses praeguse rida versiooni eemaldamine toimunud, seejärel uue lisamine.

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

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

Käsk annab ühe rea (uue versiooni):

=> SELECT * FROM t;

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

Kuid lehe peal näeme mõlemat versiooni:

=> VALI * 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 numbriga väljale xmax. Ja see väärtus on kirjutatud vana peale, kuna eelmine tehing oli tühistatud. Samuti on xmax_aborted bit lähtestatud, kuna praeguse tehingu olek on veel teadmata.

Esimene rida versioon viitab nüüd teisele (väljal t_ctid), nagu uuele.

Indeksi lehelt ilmub teine viide ja teine rida, mis viitab teisele versioonile tabelilehel.

Nagu ka kustutamisel, on xmax esimese versiooni reas märk, et rida on lukustatud.

Kokkuvõttes lõpetame tehingu.

=> COMMIT;

Indeksid

Siiani oleme rääkinud ainult tabelilehtedest. Mis juhtub indeksites?

Teave indeksilehtedes sõltub palju konkreetse indeksi tüübist. Ja isegi ühel indeksi tüübil on erinevaid lehe tüüpe. Näiteks B-puul on metainfot sisaldav leht ja 'tavalised' lehed.

Tavaliselt sisaldab leht viidete massiivi ridadele ja iseendale (nagu ka tabelilehel). Lisaks on lehe lõpus reserveeritud ruum spetsiaalsetele andmetele.

Indeksites olevatel ridades võib samuti olla väga erinev struktuur sõltuvalt indeksi tüübist. Näiteks B-puul sisaldavad lehtedele kuuluvad read indekseerimise võtme väärtust ja viidet (ctid) vastavale tabeli reale. Üldiselt võib indeks olla korraldatud täiesti erinevalt.

Oluline on märkida, et igasugustes indeksites ei ole ridade versioone. Või siis võib öelda, et iga rida on esitatud täpselt ühe versioonina. Teisisõnu, indeksirida ei sisalda välju xmin ega xmax. Võib järeldada, et indeksi viidatud lingid viivad kõikide tabeli ridade versioonideni — seega saab aru saada, millist versiooni tehing näeb, vaid vaatates tabelisse. (Kuidas tavaliselt, see pole kogu tõde. Mõnedes olukordades võimaldab nähtavuse kaart protsesside optimeerimist, kuid vaatame seda hiljem lähemalt.)

Samas lemmekandja lehelt leiame viidatud mõlema versiooni, nii aktiivse kui ka vana:

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

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

Virtuaalsed tehingud

Tavaliselt kasutab PostgreSQL optimeerimist, mis võimaldab "säästa" tehingu numbreid.

Kui tehing ainult loeb andmeid, siis ei mõjuta see ridade versioonide nähtavust. Seega alguses väljastab teenindusprotsess tehingutele virtuaalse numbri (virtual xid). Number koosneb protsessi identifikaatorist ja järjestikustest numbritest.

Selle numbri väljastamine ei vaja kõigi protsesside vahel sünkroniseerimist ja toimub seetõttu väga kiiresti. Teise põhjusega virtuaalsete numbrite kasutamiseks tutvume siis, kui räägime külmutamisest.

Virtuaalsed numbrid ei arvesta andmevõtetel.

Ajahetkedel võivad süsteemis olla virtuaalsed tehingud numbritega, mida on juba kasutatud, ja see on normaalne. Kuid sellist numbrit ei tohi andmehalduse lehtedes salvestada, kuna järgmisel pöördumisel lehele võib see kaotada igasuguse tähenduse.

=> BEGIN;
=> SELECT txid_current_if_assigned();

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

Kui tehing hakkab andmeid muutma, antakse sellele tõeline, ainulaadne tehingunumber.

=> UPDATE accounts SET amount = amount - 1.00;
=> SELECT txid_current_if_assigned();

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

=> COMMIT;

Sisemised tehingud

Salvestuspunktid

SQL-is määratletud salvestuspunktid (savepoint), mis võimaldavad tagasi võtta osa tehingu toimest, katkestamata seda täielikult. Kuid see ei vasta ülaltoodud skeemile, kuna tehingu olek on kõigi selle muudatuste jaoks ühtne ja füüsiliselt ei tagastata mingeid andmeid.

Selle funktsionaalsuse rakendamiseks jagatakse tehing koos salvestuspunktiga mitmeks eraldi sisemiseks tehinguks (subtransaction), mille olekut saab hallata eraldi.

Sisemistel tehingutel on oma numbrid (suurem kui põhitehingu number). Sisemise tehingu olek salvestatakse tavapäraselt XACT-is, kuid lõplik olek sõltub põhitehingu olekust: kui see on tühistatud, tühistatakse ka kõik sisemise tehingud.

Tehingute sisemuse teave salvestatakse failides PGDATA/pg_subtrans kataloogis. Failidele pääseb juurde eksemplari jagatud mälu puhvrite kaudu, mis on korraldatud nagu XACT-i puhvrites.

Ärge segage sissekandetud tehingute ja iseseisvate tehingute vahel. Iseseisvad tehingud ei sõltu üksteisest, samas kui sissekandetud tehingud sõltuvad. Tavalises PostgreSQL-is pole iseseisvaid tehinguid, ja see on kindlasti parem: neid on tõeliselt harva vaja ning nende olemasolu teistes andmebaasisüsteemides kutsub esile kuritarvitusi, mis mõjutavad kõiki.

Kustutame tabeli, alustame tehingut ja lisame rea:

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

 txid_current
--------------
         3669
(1 rida)

=> VALI xmin, xmax, * FROM t;

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

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

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

Nüüd paneme tahvlipunkti ja sisestame veel ühe rea.

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

 txid_current
--------------
         3669
(1 rida)

Pange tähele, et funktsioon txid_current() annab välja põhitehingu, mitte sissekandetud tehingu numbri.

=> VALI xmin, xmax, * FROM t;

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

=> VALI * 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 rida)

Tagastame tahvlipunkti ja lisame 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 rida)

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

 ctid  | seisund |   xmin   | xmax  | t_ctid 
-------+--------+----------+-------+--------
 (0,1) | normaal | 3669     | 0 (a) | (0,1)
 (0,2) | normaal | 3670 (a) | 0 (a) | (0,2)
 (0,3) | normaal | 3671     | 0 (a) | (0,3)
(3 rida)

Leheküljel näeme jätkuvalt rida, mis on lisatud tühistatud sisedoandega.

Salvestame muudatused.

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

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

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

 ctid  | seisund |   xmin   | xmax  | t_ctid 
-------+--------+----------+-------+--------
 (0,1) | normaal | 3669 (c) | 0 (a) | (0,1)
 (0,2) | normaal | 3670 (a) | 0 (a) | (0,2)
 (0,3) | normaal | 3671 (c) | 0 (a) | (0,3)
(3 rida)

Nüüd on hästi näha, et iga sisemine tehing omab oma staatust.

Tähtis on märkida, et SQL-i sees ei saa kasutada sisedoandeid, see tähendab, et ei saa alustada uut tehingut, lõpetamata praegust. See mehhanism aktiveeritakse vargsi salvestuspunktide kasutamisel, samuti PL/pgSQL eksimuste töötlemisel ja mitmetes teistes, eksootilisemates olukordades.

= > BEGIN;

BEGIN

= > BEGIN;

HOIATUS:  tehing on juba käimas
BEGIN

=> COMMIT;

COMMIT

=> COMMIT;

HOIATUS:  tehingut ei ole käimas
COMMIT

Vead ja operatsioonide aatomiseerimine

Mis juhtub, kui operatsiooni teostamisel ilmneb viga? Näiteks nii:

= > BEGIN;
= > SELECT * FROM t;

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

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

VIGA:  jagamine nulliga

Tekkis viga. Nüüd loetakse tehing peatatud ja selles ei lubata ühtegi toimingut:

=> SELECT * FROM t;

VIGA: praegune tehing on tühistatud, käsud jäetakse tähelepanuta kuni tehingu bloki lõpuni

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

=> COMMIT;

RULLI TAGASI

Miks ei saa tehingu täitmist pärast viga jätkata? Asi on selles, et viga võis tekkida nii, et saaksime osa muudatustest — oleks rikutud mitte ainult tehingu, vaid ka operaatori aatomilisust. Nagu meie näites, kus operaator suutis enne viga uuendada ühte rida:

=> VALI * 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)

Peab ütlema, et psql-is on režiim, mis siiski võimaldab tehingu jätkamist pärast viga, just nagu oleks vale operaatori toimingud tagasi rullitud.

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

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

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

VIGA:  jagamine nulliga

=> SELECT * FROM t;

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

=> COMMIT;

Ei ole raske mõista, et sellises režiimis seab psql igas käsus sisuliselt vaikimisi päästekoha, ja tõrke korral algatab see tagasi kerimise. Sellist režiimi ei kasutata vaikimisi, kuna päästekohtade seadmine (isegi ilma tagasi kerimata) toob kaasa märkimisväärseid kulusid.

Jätkub.

Allikas: habr.com