Ainsi, nous avons abordé les questions liées à l'isolement, et fait une digression sur l'organisation des données au niveau bas. Et enfin, nous sommes arrivés à la partie la plus intéressante : les versions des lignes.

L'en-tête

Comme nous l'avons déjà mentionné, chaque ligne peut exister simultanément dans la base de données sous plusieurs versions. Il faut distinguer une version de l'autre. À cette fin, chaque version a deux marqueurs qui définissent le « temps » d'application de cette version (xmin et xmax). Entre guillemets, car on n'utilise pas le temps à proprement parler, mais un compteur spécial incrémental. Et ce compteur est le numéro de transaction.

(Comme d'habitude, en réalité tout est plus complexe : le numéro de transaction ne peut pas toujours être croissant en raison de la limitation de la taille du compteur. Mais nous aborderons ces détails en profondeur lorsque nous traiterons de la congélation.)

Lorsqu'une ligne est créée, la valeur de xmin est définie par le numéro de la transaction qui a exécuté la commande INSERT, et xmax n'est pas rempli.

Lorsque la ligne est supprimée, la valeur de xmax de la version actuelle est marquée par le numéro de la transaction qui a exécuté DELETE.

Lorsqu'une ligne est modifiée par la commande UPDATE, deux opérations sont en fait effectuées : DELETE et INSERT. Dans la version actuelle de la ligne, xmax est défini sur le numéro de transaction qui a exécuté UPDATE. Ensuite, une nouvelle version de la même ligne est créée ; sa valeur de xmin correspond à la valeur de xmax de la version précédente.

Les champs xmin et xmax font partie de l'en-tête de la version de la ligne. En plus de ces champs, l'en-tête contient d'autres informations, par exemple :

• infomask — une série de bits définissant les propriétés de cette version. Il y en a pas mal ; nous examinerons progressivement les principales.
• ctid — un lien vers la version suivante, plus récente de la même ligne. Pour la version la plus récente, ctid pointe vers elle-même. Le numéro est de la forme (x,y), où x est le numéro de la page et y est le numéro ordinal du pointeur dans le tableau.
• carte des valeurs indéfinies — marque les colonnes de cette version qui contiennent une valeur indéfinie (NULL). NULL n'est pas l'une des valeurs habituelles des types de données, c'est pourquoi il faut stocker ce critère séparément.

En conséquence, l'en-tête devient assez volumineux — au moins 23 octets pour chaque version de ligne, et généralement plus en raison de la carte des NULL. Si la table est « étroite » (c'est-à-dire contient peu de colonnes), les frais généraux peuvent dépasser l'information utile.

Insertion

Examinons en détail comment les opérations sur les chaînes se déroulent à un niveau bas, en commençant par l'insertion.

Pour nos expériences, créons une nouvelle table avec deux colonnes et un index sur l'une d'elles :

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

Insérons une ligne après avoir commencé la transaction.

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

Voici le numéro de notre transaction actuelle :

=> SELECT txid_current();

 txid_current 
--------------
         3664
(1 ligne)

Regardons le contenu de la page. La fonction heap_page_items de l'extension pageinspect permet d'obtenir des informations sur les pointeurs et les versions des lignes :

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

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

Notons que par le terme heap (tas) dans PostgreSQL, nous faisons référence aux tables. C'est une autre utilisation étrange du terme – le tas est une structure de données, qui n'a rien à voir avec une table. Ici, ce mot est utilisé dans le sens de « tout est entassé », par opposition aux index ordonnés.

La fonction montre les données « telles quelles », dans un format difficile à interpréter. Pour comprendre, nous allons conserver seulement une partie de l'information et la déchiffrer :

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

-[ ENREGISTREMENT 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)

Voici ce que nous avons fait :

• Nous avons ajouté un zéro au numéro du pointeur pour le mettre dans le même format que t_ctid : (numéro de page, numéro de pointeur).
• Nous avons déchiffré l'état du pointeur lp_flags. Ici, il est « normal » - cela signifie que le pointeur fait effectivement référence à la version de la ligne. Nous examinerons d'autres valeurs plus tard.
• Parmi tous les bits d'information, nous avons pour l'instant isolé seulement deux paires. Les bits xmin_committed et xmin_aborted indiquent si la transaction numérotée xmin a été validée (annulée). Deux bits similaires concernent la transaction numérotée xmax.

Que voyons-nous ? Lors de l'insertion d'une ligne dans une page de table, un pointeur apparaîtra avec le numéro 1, faisant référence à la première et unique version de la ligne.

Dans la version de la ligne, le champ xmin est rempli avec le numéro de la transaction actuelle. La transaction est encore active, donc les deux bits xmin_committed et xmin_aborted ne sont pas définis.

Le champ ctid de la version de la ligne fait référence à cette même ligne. Cela signifie qu'aucune version plus récente n'existe.

Le champ xmax est rempli avec le numéro fictif 0, car cette version de la ligne n'est pas supprimée et est actuelle. Les transactions ne prêteront pas attention à ce numéro, car le bit xmax_aborted est défini.

Faisons un pas de plus vers l'amélioration de la lisibilité en ajoutant des bits d'information aux numéros de transaction. Et créons une fonction, car cette requête nous sera nécessaire plus d'une fois :

=> 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;

Sous cette forme, il est beaucoup plus clair de voir ce qui se passe dans l'en-tête de la version de la ligne :

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

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

On peut obtenir des informations similaires, mais beaucoup moins détaillées, directement à partir de la table en utilisant les pseudocolonnes xmin et xmax :

=> SELECT xmin, xmax, * FROM t;

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

Validation

À la fin réussie d'une transaction, il est nécessaire de mémoriser son statut — de marquer qu'elle a été validée. Pour cela, on utilise une structure appelée XACT (et auparavant, jusqu'à la version 10, elle était appelée CLOG (commit log) et ce terme peut encore apparaître à divers endroits).

XACT n'est pas une table de catalogue système ; ce sont des fichiers dans le répertoire PGDATA/pg_xact. Pour chaque transaction, deux bits sont alloués : committed et aborted — tout comme dans l'en-tête de la version de la ligne. Ces informations sont réparties sur plusieurs fichiers uniquement pour des raisons de commodité, nous reviendrons sur ce sujet lorsque nous examinerons la congélation. Et la manipulation de ces fichiers se fait page par page, comme pour tous les autres.

Ainsi, lors de l'engagement d'une transaction dans XACT, le bit "committed" est défini pour cette transaction. C'est tout ce qui se passe lors de l'engagement (pour l'instant, nous ne parlons pas du journal de pré-écriture).

Lorsque toute autre transaction accède à la page de la table que nous venons de voir, elle devra répondre à plusieurs questions.

1. La transaction a-t-elle été complétée ? Si ce n'est pas le cas, la version de la ligne créée ne doit pas être visible.
   Cette vérification est effectuée en consultant une autre structure qui se trouve dans la mémoire partagée de l'instance et qui s'appelle ProcArray. Elle contient la liste de tous les processus actifs, et pour chacun est indiqué le numéro de sa transaction actuelle (active).
2. Si elle a été complétée, comment — par un engagement ou un rollback ? Si par un rollback, alors la version de la ligne ne doit également pas être visible.
   C'est justement pour cela que XACT est nécessaire. Cependant, bien que les dernières pages de XACT soient conservées dans des buffers en mémoire vive, vérifier XACT à chaque fois serait coûteux. Par conséquent, le statut de la transaction, une fois déterminé, est enregistré dans les bits xmin_committed et xmin_aborted de la version de la ligne. Si l'un de ces bits est activé, l'état de la transaction xmin est considéré comme connu et la transaction suivante n'aura plus à consulter XACT.

Pourquoi ces bits ne sont-ils pas définis par la transaction qui effectue l'insertion ? Lors d'une insertion, la transaction ne sait pas encore si elle se terminera avec succès. Et au moment de l'engagement, il n'est déjà pas clair quelles lignes dans quelles pages ont été modifiées. Il peut y avoir beaucoup de telles pages, et il serait peu rentable de les mémoriser. De plus, certaines pages peuvent avoir été évincées du cache tampon sur le disque ; les lire à nouveau pour modifier les bits signifierait ralentir considérablement l'engagement.

Le revers de l'économie est que, après des modifications, toute transaction (même celle effectuant une simple lecture — SELECT) peut commencer à modifier les pages de données dans le cache tampon.

Ainsi, engageons le changement.

=> COMMIT;

Rien n'a changé dans la page (mais nous savons que le statut de la transaction est déjà enregistré dans XACT) :

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

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

Maintenant, la transaction qui a accédé en premier à la page devra déterminer le statut de la transaction xmin et l'enregistrera dans les bits d'information :

=> SELECT * FROM t;

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

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

 ctid  | état  |   xmin   | xmax  | t_ctid 
-------+--------+----------+-------+--------
 (0,1) | normal | 3664 (c) | 0 (a) | (0,1)
(1 ligne)

Désinstallation

Lors de la suppression d'une ligne, le champ xmax de la version actuelle enregistre le numéro de la transaction de suppression en cours, tandis que le bit xmax_aborted est réinitialisé.

Notons que la valeur xmax, correspondant à la transaction active, agit comme un verrouillage de ligne. Si une autre transaction tente de mettre à jour ou de supprimer cette ligne, elle sera obligée d'attendre la fin de la transaction xmax. Nous parlerons plus en détail des verrouillages plus tard. Pour l'instant, notons simplement qu'il n'y a aucune limite au nombre de verrouillages de lignes. Ils n'occupent pas d'espace dans la mémoire vive et la performance du système ne souffre pas de leur nombre. Cependant, les transactions "longues" présentent d'autres inconvénients, mais nous en parlerons également plus tard.

Supprimons la ligne.

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

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

Nous voyons que le numéro de transaction a été enregistré dans le champ xmax, mais que les bits d'information ne sont pas activés :

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

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

Annulation

L'annulation des modifications fonctionne de la même manière que le commit, sauf que dans XACT pour la transaction, le bit aborted est défini. L'annulation s'exécute aussi rapidement que le commit. Bien que la commande soit appelée ROLLBACK, les changements ne sont pas annulés : tout ce que la transaction a réussi à modifier dans les pages de données reste inaltéré.

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

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

Lors de l'accès à la page, le statut sera vérifié et le bit de l'indice xmax_aborted sera défini dans la version de la ligne. Le numéro xmax reste sur la page, mais personne ne le regardera désormais.

=> SELECT * FROM t;

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

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

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

Mise à jour

La mise à jour fonctionne comme si la suppression de la version actuelle de la ligne avait été effectuée, suivie de l'insertion d'une nouvelle.

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

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

La requête retourne une ligne (la nouvelle version) :

=> SELECT * FROM t;

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

Mais sur la page, nous voyons les deux versions :

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

La version supprimée est marquée par le numéro de la transaction en cours dans le champ xmax. De plus, cette valeur est écrite par-dessus l'ancienne, puisque la transaction précédente a été annulée. Et le bit xmax_aborted est réinitialisé, car le statut de la transaction actuelle est encore inconnu.

La première version de la ligne fait maintenant référence à la seconde (champ t_ctid), comme à une version plus récente.

Dans la page d'index, un deuxième pointeur et une deuxième ligne apparaissent, se référant à la deuxième version dans la page de table.

Tout comme lors de la suppression, la valeur xmax dans la première version de la ligne indique que la ligne est verrouillée.

Et nous terminerons la transaction.

=> COMMIT;

Indices

Jusqu'à présent, nous avons uniquement parlé des pages de table. Que se passe-t-il à l'intérieur des indices ?

Les informations dans les pages d'index dépendent fortement du type spécifique d'index. Même au sein d'un même type d'index, il peut y avoir différents types de pages. Par exemple, un arbre B contient une page de métadonnées et des pages « ordinaires ».

Cependant, en général, une page contient un tableau de pointeurs vers des lignes et les lignes elles-mêmes (tout comme dans une page de table). De plus, à la fin de la page, de l'espace est réservé pour des données spéciales.

Les lignes dans les indices peuvent également avoir des structures très variées selon le type d'index. Par exemple, pour un arbre B, les lignes liées aux pages feuilles contiennent la valeur de la clé d'indexation et un lien (ctid) vers la ligne correspondante de la table. En général, un index peut être structuré de manière complètement différente.

Le point le plus important est que dans les indices de tout type, il n'y a pas de versions de lignes. Ou l'on peut considérer que chaque ligne est représentée par exactement une version. En d'autres termes, dans l'en-tête de la ligne d'index, il n'y a pas de champs xmin et xmax. On peut considérer que les liens dans l'index pointent vers toutes les versions de table des lignes — donc pour comprendre laquelle des versions une transaction verra, il faut consulter la table. (Comme d'habitude, ce n'est pas toute la vérité. Dans certains cas, la carte de visibilité permet d'optimiser le processus, mais nous en discuterons plus en détail plus tard.)

Dans la page d'index, nous trouvons des pointeurs vers les deux versions, à la fois la actuelle et l'ancienne :

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

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

Transactions virtuelles

En pratique, PostgreSQL utilise une optimisation qui permet de « sauver » les numéros de transaction.

Lorsqu'une transaction ne fait que lire des données, elle n'influence en rien la visibilité des versions des lignes. Par conséquent, au début, le processus de service attribue un numéro virtuel à la transaction (virtual xid). Ce numéro est composé d'un identifiant de processus et d'un numéro séquentiel.

L'attribution de ce numéro ne nécessite pas de synchronisation entre tous les processus et s'effectue donc très rapidement. La deuxième raison d'utiliser des numéros virtuels sera abordée lorsque nous parlerons de la suspension.

Les numéros virtuels ne sont pas pris en compte dans les clichés de données.

À différents moments, le système peut contenir des transactions virtuelles avec des numéros déjà utilisés, ce qui est normal. Mais un tel numéro ne peut pas être enregistré dans les pages de données, car lors de la prochaine référence à la page, il peut perdre toute signification.

=> DÉBUT;
=> SÉLECTIONNER txid_current_if_assigned();

 txid_current_if_assigned 
--------------------------
                         
(1 ligne)

Si une transaction commence à modifier des données, elle reçoit un véritable numéro de transaction unique.

=> METTRE À JOUR comptes SET montant = montant - 1,00;
=> SÉLECTIONNER txid_current_if_assigned();

 txid_current_if_assigned 
--------------------------
                     3667
(1 ligne)

=> COMMIT;

Transactions imbriquées

Points de sauvegarde

En SQL, sont définis points de sauvegarde (savepoint), qui permettent d'annuler une partie des opérations d'une transaction sans l'interrompre complètement. Cependant, cela ne s'intègre pas dans le schéma ci-dessus, car le statut d'une transaction est unique pour tous ses changements, et aucune donnée n'est physiquement annulée.

Pour réaliser une telle fonctionnalité, la transaction avec un point de sauvegarde est divisée en plusieurs transactions imbriquées (subtransaction), dont le statut peut être géré indépendamment.

Les transactions imbriquées ont leur propre numéro (plus grand que le numéro de la transaction principale). Le statut des transactions imbriquées est enregistré de manière habituelle dans XACT, mais le statut final dépend de celui de la transaction principale : si elle est annulée, alors toutes les transactions imbriquées le sont également.

Les informations sur l'imbrication des transactions sont stockées dans des fichiers dans le répertoire PGDATA/pg_subtrans. L'accès aux fichiers se fait par l'intermédiaire de buffers en mémoire partagée de l'instance, organisés de la même manière que les buffers XACT.

Ne confondez pas les transactions imbriquées et les transactions autonomes. Les transactions autonomes ne dépendent pas les unes des autres, alors que les imbriquées le font. Il n'y a pas de transactions autonomes dans PostgreSQL standard, et c'est probablement mieux ainsi : elles ne sont nécessaires que très rarement, et leur présence dans d'autres systèmes de gestion de bases de données peut provoquer des abus dont tout le monde souffre par la suite.

Nous allons vider la table, commencer la transaction et insérer une ligne :

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

 txid_current 
--------------
         3669
(1 ligne)

=> SELECT xmin, xmax, * FROM t;

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

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

 ctid  | état  | xmin | xmax  | t_ctid 
-------+--------+------+-------+--------
 (0,1) | normal | 3669 | 0 (a) | (0,1)
(1 ligne)

Maintenant, nous allons définir un point de sauvegarde et insérer une autre ligne.

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

 txid_current 
--------------
         3669
(1 ligne)

Notez que la fonction txid_current() retourne le numéro de la transaction principale, et non celle imbriquée.

=> SELECT xmin, xmax, * FROM t;

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

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

 ctid  | état  | xmin | xmax  | t_ctid 
-------+--------+------+-------+--------
 (0,1) | normal | 3669 | 0 (a) | (0,1)
 (0,2) | normal | 3670 | 0 (a) | (0,2)
(2 lignes)

Revenons au point de sauvegarde et insérons une troisième ligne.

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

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

 ctid  | état  |   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 lignes)

Sur la page, nous continuons à voir la ligne ajoutée par la transaction imbriquée annulée.

Validons les modifications.

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

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

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

 ctid  | état  |   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 lignes)

Il est maintenant clair que chaque transaction imbriquée a son propre état.

Notons que les transactions imbriquées ne peuvent pas être utilisées explicitement dans SQL, c'est-à-dire qu'il n'est pas possible de commencer une nouvelle transaction sans avoir terminé l'actuelle. Ce mécanisme est utilisé implicitement lors de l'utilisation des points de sauvegarde, ainsi que lors du traitement d'exceptions PL/pgSQL et dans certains autres cas plus exotiques.

=> BEGIN;

BEGIN

=> BEGIN;

AVERTISSEMENT : il y a déjà une transaction en cours
BEGIN

=> COMMIT;

COMMIT

=> COMMIT;

AVERTISSEMENT : il n'y a pas de transaction en cours
COMMIT

Erreurs et atomicité des opérations

Que se passera-t-il si une erreur se produit lors de l'exécution d'une opération ? Par exemple, comme suit :

=> BEGIN;
=> SELECT * FROM t;

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

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

ERREUR : division par zéro

Une erreur s'est produite. La transaction est maintenant considérée comme interrompue et aucune opération ne peut être effectuée dans celle-ci :

=> SELECT * FROM t;

ERREUR : la transaction actuelle est annulée, les commandes sont ignorées jusqu'à la fin du bloc de transaction

Et même si vous essayez de valider les modifications, PostgreSQL indiquera une annulation :

=> COMMIT;

ROLLBACK

Pourquoi ne peut-on pas continuer l'exécution d'une transaction après un échec ? En fait, l'erreur aurait pu survenir de telle manière que nous aurions accès à une partie des modifications — l'atome aurait été rompu, même pas la transaction, mais l'opérateur. Comme dans notre exemple, où l'opérateur a réussi à mettre à jour une ligne avant l'erreur :

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

Il convient de noter qu'il existe un mode dans psql qui permet néanmoins de continuer l'exécution de la transaction après une erreur, comme si les actions de l'opérateur erroné étaient annulées.

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

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

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

ERREUR : division par zéro

=> SELECT * FROM t;

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

=> COMMIT;

Il n'est pas difficile de deviner que dans ce mode, psql place effectivement un point de sauvegarde implicite avant chaque commande, et en cas d'échec, initie un retour à ce point. Ce mode n'est pas activé par défaut, car la mise en place de points de sauvegarde (même sans retour) entraîne des coûts opérationnels significatifs.

Continuer.

Source : habr.com